[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: DEP-14: Recommended layout for Git packaging repositories


2014-11-12 10:28 GMT+01:00 Raphael Hertzog <hertzog@debian.org>:
> On Wed, 12 Nov 2014, Mathieu Parent wrote:
>> A paragraph about repacked upstream is needed. A lot of packages are
>> currently stripped for minified JS, non-free additions, included RFCs,
>> ... What would the upstream/1.x branch be then? Maybe add an
>> upstream/1.x+debian branch?
> Yeah, that was another open question I had.
> There's no clear conventions about how to handle the removal of files from
> upstream releases.
> It looks like some people are using uscan/mk-origtaz to drop non-DFSG
> files from the downloaded .tar.gz (via Files-Excluded in debian/copyright)
> and then the "upstream" branch is directly the DFSG clean version.
> But other persons are using "dfsg" branches where they handle the removal
> of the problematic files and they merge those branches. So their process
> is:
> - update the dfsg branch by merging the upstream release
> - merge the dfsg branch in the debian packaging branch
> There are probably other workflows.
> I'm not sure what's best. But given that the whole "upstream" namespaces
> is a packaging artifact, it would seem natural that those branches contain
> the upstream sources as we define them, i.e. with the non-free files already
> stripped.

OK. Makes sense. The unstripped upstream can then live in an
non-namespaced branch if needed (this is not my usual workflow but
should be possible).

Maybe a short note would be good then? (but I don't know how to write it).

> I would thus limit ourselves to stating that and not having any specific
> recommendations on how people should get rid of the files.
> Does that sound reasonable?


>> Also, the vendor/* branches heads should be at a descendent commit of
>> the corresponding upstream branch, diffing only by the debian dir.
> Does that need to be explicitly stated?

The "What to store in the Git repository" first paragraph is enough.



Reply to: