Hi all, > -<emphasis role="strong">must</emphasis> contain detailed information how the > -repackaged source was obtained, and how this can be reproduced in the > +<emphasis role="strong">must</emphasis> be documented. Detailed information on how the > +repackaged source was obtained, and on how this can be reproduced must be provided in > <filename>debian/copyright</filename>.
What format should this "detailed" description be in? How detailed? * A description in words of what was done: "The non-free font files were deleted from the source tarball" * A description in commands of what was done: "find -name \*.ttf -delete" * A brief description with a pointer to a log of what was done? "The non-free font files were were stripped from the downloaded file to create the 'orig' source package. See the file README.Debian-source for full details." I like the last of these the best, where the log file is generated from a standard (yet to be decided!) repackaging tool that clearly shows what was originally downloaded and what was done to it. Perhaps it's also time to start thinking about how the machine-readable copyright files [1] fit into this. [1] http://wiki.debian.org/Proposals/CopyrightFormat Since the point of the machine-readable copyright proposal is to remove arbitrary free form lumps of text from this file, it is perhaps opportune to consider the side-effects of this new language on that proposal which mandate the inclusion of unspecified amounts of "details". (Despite the efforts of two or three contributors to the copyright format proposal, there is still nowhere to include anything about repackaging; the suggested fields are routinely removed -- perhaps this illustrates a shortcoming of a wiki for writing such documents more than anything else!) > It is also a good idea to provide a > <literal>get-orig-source</literal> target in your > <filename>debian/rules</filename> file that repeats the process, as described Is this wording is slightly at odds with what policy 4.9? (Although that is a matter of interpretation that can't be agreed upon, it would seem, see #466550.) > get-orig-source (optional) > > This target fetches the most recent version of the original source > package from a canonical archive site (via FTP or WWW, for example), does > any necessary rearrangement to turn it into the original source tar file > format described below, and leaves it in the current directory. Thus policy currently states that get-orig-source should (a) fetch the tarball and (b) repackage it, while the wording in that patch to devref only has get-orig-source repackaging the tarball. There is then the old chestnut of what one means by "most recent" source for the get-orig-source target. Presumably one doesn't mean the most recent release from upstream as we already have uscan to do that. Using get-orig-source only to do the repackaging to regenerate the debian orig tarball would seem to make the most sense. I wonder if the work to clean up this part of devref actually needs to be part of a wider effort to work out what is meant by get-orig-source and to appropriately document it. Placing yet another divergent interpretation of get-orig-source into devref doesn't seem to work towards that goal. food for thought! cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org