Web lists-archives.com

Re: Repackaging upstream source with file modifications?




Quoting Colin Watson (2018-02-12 13:18:04)
> On Mon, Feb 12, 2018 at 12:09:50PM +0000, Wookey wrote:
> > On 2018-02-12 11:22 +0000, Colin Watson wrote:
> > > Huh.  I hadn't thought of that option, but it seems peculiar and
> > > excessively baroque (it basically splits the patch into a remove and an
> > > add, making it less obviously identical to the one submitted upstream
> > > and harder to keep track of in git).  Is there a strong reason to take
> > > that approach?
> > 
> > I'd have done the same as Simon. The main advantage is that it makes
> > the tarball free software, which we generally don't get any leeway
> > about
> 
> The same advantage is gained by simply patching the replacement code
> into the regenerated tarball in a single step, rather than removing in
> one step and adding in another.

The tarball should contain only upstream code.  Not patched code (then 
you arguably are making a fork).

Omitting some files when redistributing an upstream project is common 
and well-documented - please follow that same pattern.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature