Bill Allombert wrote: > 1) We should move to new source package format (3.0 etc) that remove the > need for patch system altogether.
Oh, yes please. But, as I currently understand it, existing packages will
not magically start using this format, and thus we are likely to find
ourselves growing a large number of these distracting files, even beyond
100% coverage of the 3.0 formats.
Besides, it might also help to clarify the situation for old-style packages
using patch systems, simply as a means of better defining positive uses of
README.source to move forward with.
As two concrete examples, a maintainer using the "quilt" 3.0 format may
still include a README.source that directs the reader towards the presence
of patches and other miscellania.
In addition, I have seen README.source files that give "crash courses" on
how to use pbuilder in a generic fashion. I would consider this to be rather
inappropriate, regardless of the package format.
> 3) If a package is lacking debian/README.source, then one should expect
> that the source is ready to be used. If it not the case, even an empty
> debian/README.source is better than none.
I believe our disagreement here is that I feel curbing the proliferation of
distracting README.source files is more important than maintaining a "no
README.source => package is ready" invariant.
However, this invariant doesn't seem particularly useful as we still have to
rely on heuristics to prepare a package (whatever that means).
As an illustration of its current deficiencies, a static analysis tool
running across the archive still has to guess whether to apply patches,
extract embedded-tarballs and such forth - the presence or lack of a
README.source by your specification is not helpful. You can replace "static
analysis tool" with NMUer/porter without major issue here too.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org
`-
signature.asc
Description: PGP signature
