Le 12/11/2014 12:25, Raphael Hertzog a écrit : > Hi, > > On Wed, 12 Nov 2014, Thibaut Paumard wrote: >> I see nothing about whether the debian branch should contained the >> unpacked or the unpacked *and* patched sources, and whether to ship the >> .pc directory. > > That's a volunteer choice at this stage. We have different workflows > that are worth supporting and they differ at this level of details.
Dear Raphaël, I see that some people feel very strongly that the source should be in patch-applied state. Some tools require it. I am very strongly of the opposite opinion (for reasons detailed below). You are right that this DEP should not mandate one over the other (actually this DEP is a "best practices" document, so strictly speaking it doesn't mandate anything). However, we should perhaps strongly recommend that this choice be documented in debian/README.sources. Not that it's very relevant, to each his own, but since I see advocacies for the patch-applied state. I'm not trying to convince anyone, but here is why I chose patch-unapplied: We have a very nice source package format with "3.0 (quilt)". In this format, we simply have the pristine upstream source, with an additional debian directory that contains all the packaging stuff. Features are nicely separated as feature patches. I think the only workflow that newcomers and NMUers should be required to learn is the one that involves quilt, they should not be expected to learn (e.g.) dgit in addition. Also, we need to document the debian/patches à la DEP3. So the way our modifications to the upstream source are stored should be in debian/patches/, independent on whether we use the tar.gz archives or svn or git. If these modifications are stored already in debian/patches, representing them also in git in the upstream code is a pointless duplication of the same information. With the patch-unapplied scheme, I can do: git diff upstream master and check that there is nothing changed above the debian/ directory. Likewise, I can do git diff debian/1.0.0-1 debian/1.0.0-2 and check the changes that will be represented in the source package. So to me, the patch-unapplied scheme is easier to understand and less error prone. Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
