Jörg Sommer <[EMAIL PROTECTED]> writes: > Russ Allbery schrieb am Tue 01. Jan, 22:54 (-0800):
>> + <file>debian/README.source</file> documentation file is >> + recommended. This file should explain how to do all of the >> + following: >> + <enumlist> >> + <item>Generate the fully patched source, in a form ready for >> + editing, that would be built to create Debian >> + packages. Doing this with a <tt>patched</tt> target in >> + <file>debian/rules</file> is recommended; see >> + <ref id="debianrules">.</item> >> + <item>Modify the source and save those modifications so that >> + they will be applied when building the package.</item> >> + <item>Remove existing source modifications that previously >> + were applied.</item> > > Should this be the opposite of the first item or should this describe > how to remove user modifications, i.e. bring the tree in the state after > doing debian/rules patched? What I was trying to get at here was documentation on how to remove a patch that was previously in the Debian package but which should go away for some reason (perhaps it introduces a security vulnerability). So it's not really related to the first item. I'll try to think of a better way of phrasing that. > The rest looks good and I agree that such a source is useful, but it > should also be allowed to refer to a central document like > /u/s/d/dpatch/README.source. I expect that many README.source look the > same. I don't think that needs any change to the above wording. If README.source refers to another existing file that documents those things, that seems to me to satisfy the above. Although I suppose we could explicitly add something like "The instructions may refer to a documentation file installed by one of the package build dependencies, provided that it clearly explains these tasks and isn't a general reference manual." -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
