Re: DEP5: non-DFSG repackaging documentation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think at this point, we have to solve other problems with policy and
devref, and having solved them the correct outcome for DEP5 will become
obvious.
> - if the transformation can be expressed as a script, use "debian/rules
> get-orig-source"
Since the purpose of the get-orig-source target seems to have become unclear
over time, this doesn't sound like a good plan to me. The particular
problems with this target are summarised in
http://bugs.debian.org/466550
The main conclusion of the discussion there was that the get-orig-source
target should probably go away. To summarise (roughly, apologies to those
whose pet argument is omitted):
* Why is the target is supposed to _fetch_ the most recent version (policy
§4.9)? We have uscan for that already.
* What does "orig" mean anyway? "orig" meaning the source for the current
package you're working on or "orig" meaning the next upstream source? (i.e.
is this duplicating apt-get source or uscan?)
* what does "orig" mean in the context of a repackaged tarball?
Basically, get-orig-source currently overlaps with one or both of uscan and
apt-get source.
It would seem that at best get-orig-source is poorly named; is there really
a sane way of changing its meaning to really mean make-repackaged-source?
> - otherwise, debian/README.Source seems like a better place to document
> this than debian/copyright, since it has other instructions for creating
> the source package, too
My reading of Policy §4.14 is that README.source currently has a very
different role to documenting the removal of files. This file is there to
explain patch systems that might be in use (see for
example /usr/share/doc/quilt/README.source) or to document
tarball-in-tarball source packages.
Meanwhile, Policy §12.5 and devref §4.14 both point to debian/copyright as
the place to document where the source came from.
Another related discussion on the matter that resulted in (a) a few
clean-ups and (b) a conclusion that further discussion and cleaning up was
required, can be found at:
http://bugs.debian.org/492661
> Thus I would prefer it if DEP5 was silent on this, and Dev-ref would be
> changed to point to get-orig-source and README.Source instead.
(I liked README.Debian-source for this... but that went away.)
Given that we re-entered the DEP-5 discussions with the very explicit
statement that the format was only going to document what was in Policy and
provide a format for that, then we would seem to be stuck with this
information in debian/copyright for the time being. DEP-5 is about
providing a way of writing down what we are required by policy to include
in debian/copyright and not about changing policy itself. As has been
illustrated a number of times in discussions about including lists of
copyright holders in debian/copyright, mixing discussions about DEP-5 with
discussions about changes to either policy or current practices is a
dangerous game to play. So perhaps there are reasons to change where
repackaging is documented, but as has been noted at least once during these
discussions, this is the wrong place for the discussion and it shouldn't
get tangled up with DEP-5 discussions.
http://lists.debian.org/20100815183520.GF19959@dario.dodds.net
I'd suggest that we either
* put fields in DEP-5 to account for such repackaging in the knowledge that
they will be moved/removed later when/if policy and devref are changed
* put this part of the discussion on hold until policy and devref are either
changed or the current position confirmed through the existing policy
process.
Personally, I'd like a nice machine-readable list of files/dirs/globs that
should be removed from the tarball. I'd like it to be kept in a canonical
location in the source tarball (debian/copyright, perhaps?) and have a nice
dh_* or dpkg-* tool that could take an upstream tarball and produce exactly
the same repackaged tarball each time from that. I have a (crappy little)
script to do so in a couple of my packages and it generates a
README.Debian-source in which the exact transformations that were applied
to the source tarball are listed and this file is referenced from
debian/copyright so that people can find out the exact details of the
repacking should they be interested. While it's presumably not possible to
have a completely universal repackaging tool, the common case is just
omitting files and I use exactly the same simple script on 4 source
packages. (And yes, I know I just volunteered to work on such a tool, once
#492661, #466550, #561494 and DEP-5 are sorted out...)
That's my 2¢,
Stuart
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkyOrqkACgkQn+i4zXHF0aj9iQCfd9wvBmUSiTHy5ExlkFHEyhv2
moYAnRQ6yCqebPHgj4dIr1kiP1x51uM/
=Zjo7
-----END PGP SIGNATURE-----
Reply to: