Russ Allbery writes ("Re: Task list for a policy release"):
> #379150: Documentation for Breaks in dpkg
>
> This support was added in dpkg 1.14.6, so I'm inclined to accept and
> commit this patch. I trust Ian to document the feature, and the wording
> seems fine to me. The only caveat is that I don't know if we're ready to
> accept Breaks fields in the archive already, and I'm not sure who to ask
> about that or how to decide it (ftp-master?).
I would suggest not using Breaks in lenny (unfortunately), except for
the special case where the combination to be avoided exists only in
lenny.
Any Breaks in packages in lenny will be ignored by the package system
when upgrading from etch to lenny. This is because of our (IMO
wrongheaded) approach of trying to do upgrades from etch to lenny
using etch's packaging tools - but it's probably too hard to do
something about that at this stage.
> #250202: [PROPOSAL] "debian/README.source" file for packages with
> non-trivial source
>
> Bleh. This is kind of a mess.
>
> I don't like the last wording proposal in that it advocates strongly
> against using quilt or dpatch, which as near as I can tell from other
> Debian mailing list discussion and packaging teams are widely considered
> best practices inside Debian even though they don't immediately give you
> editable source.
quilt and dpatch are commonly used but as someone who has done
extensive work on packages for which I wasn't the Debian maintainer I
would like to put on record that they are IMO very much _not_ best
practice.
Best practice is to use a proper revision control system (one which
can do patch stack management if that's desired) and generate a
consolidated .dsc/.diff.gz for people who don't want to get to grips
with it.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
