Hi,
There have been two suggestions to fix this issue:
* Mandate common names for debian/rules targets,
* Use a debian/README.source to document used debian/rules targets.
At first sight, these seem to be conflicting, especially if one
considers Bill's objection to suggesting names. However, as I understand
Bill, his main problem is with the fact that suggesting names might make
it sound like a good idea to use such targets. After thinking about this
problem, however, I made an attempt to write a paragraph, the language
of which makes it clear that it is /not/ a good idea to create such a
package, but if one really has to, yada yada.
That being said, a recent post on -devel by Lars Wirzenius[1] made me
realize that this problem is about more than (c)dbs; thus, I've changed
the concept to make it broader.
I'm hereby rescinding all previous proposals I made on #250202, to
replace them with the following:
--- policy.sgml.orig 2005-04-26 11:02:02.000000000 +0200
+++ policy.sgml 2005-04-26 11:28:10.000000000 +0200
@@ -2098,6 +2098,43 @@
the file to the list in <file>debian/files</file>.</p>
</sect>
+ <sect id="readmesource">
+ <heading>Source package handling:
<file>debian/README.source</file></heading>
+ <p>
+ It is assumed that for any Debian package, by running
+ <prgn>dpkg-source -x</prgn> one can edit files in the
+ package and build a modified version. This is a good thing;
+ it allows people not familiar with the package to easily
+ edit it to prepare non-maintainer uploads, security uploads,
+ or local modified versions; it also easily allows people to
+ automatedly audit the source, or to generate statistics over
+ a large portion of the source packages in the
+ archive. Maintainers should, therefore, try to avoid doing
+ anything which might break this assumption.</p>
+ <p>
+ If, even after this warning, a maintainer still chooses to
+ do so by either creating the layout of the source package
+ such that running <prgn>dpkg-source -x</prgn> does not
+ render editable source, or by managing files anywhere in the
+ package in such a way that running
+ <prgn>dpkg-buildpackage</prgn> may overwrite changes, then
+ they should create a file <file>debian/README.source</file>
+ documenting the way the source package is structured; such a
+ file would typically explain to someone not familiar with
+ the package how to create a modified version of the
+ package. It would also document any gotchas one might
+ encounter.</p>
+ <p>
+ In addition, maintainers should create a target
+ <tt>source</tt> to the <prgn>debian/rules</prgn> file. This
+ target, if present, should unpack source archives, apply
+ patches, generate files, and generally prepare the unpacked
+ source package to modification. Running <prgn>debian/rules
+ binary</prgn> after <prgn>debian/rules source</prgn>
+ <em>must not</em> erase any changes, and it must also not
+ fail.
+ </p>
+
</chapt>
I think this wording is discouraging enough towards using tarballs in
source packages, while OTOH still allowing it *and* requesting people to
document anything out of the ordinary. I think this is a compromise that
includes all viewpoints, but I'm of course open to other suggestions.
I'm looking for seconds.
[1] http://lists.debian.org/debian-devel/2005/04/msg01006.html
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
