Re: presumable last policy change before releasing Squeeze?
ERSEK Laszlo <lacos@caesar.elte.hu> writes:
> This is tedious and doesn't bring anything to users, so instead of
> rushing it and possibly making several Policy rounds until Squeeze
> ships
Don't do that. It's deprecated practice to have an upload that *only*
addresses Standards-Version; it should only ever be updated as part of a
new release being made for *other* reasons, since there's nothing wrong
with a package conforming with a slightly out-of-date Standards-Version.
> I'd like to concentrate it into one session/upload. In this case
> package tidyness through less work is more important to me than
> package availability, since it won't bring anything to users, just
> keep my stuff neat.
I only ever consider updating the Standards-Version of a package when
I'm already working on the package anyway. From reading other package
changelogs, it seems this is the normal way to do it.
> Are you saying that I should update the package as soon as said
> external stuff allows, and go with the then-current Policy version
> into Sqeeze, leaving my sponsor and the build network more time as
> well?
Yes, make a release whenever you think a new release is justified by
significant changes in either a new upstream version or the packaging
work. Conformance with latest Policy is not by itself sufficient
motivation for a new release.
Whenever you're already working on the package for other reasons, check
the latest version of Policy each time and make any changes necessary to
comply with the latest Standards-Version. Each new Policy release has a
helpful summary of changes that Debian package maintainers need to be
aware of; read them thoroughly and understand what changes you need to
make as a result.
You should be using the ‘lintian(1)’ tool in some kind of automated test
each time you build your package, which will test your package for
various problems including many that would be Policy violations (among
many other checks). The maintainer of that tool is also involved in
administration and development of Policy, so the tool is usually quite
up-to-date with the latest Policy.
If you routinely follow best practices as found in the various developer
documents for Debian (<URL:http://www.debian.org/doc/#righthalfcol> or
the corresponding document packages installed to your system), then you
will commonly find that your package needs no special changes even when
there is a new Policy version released. My ‘debian/changelog’ entries
frequently have items like:
* Conform to ‘Standards-Version: 3.8.3’. No additional changes needed.
This allows readers (including those involved in getting the package
into the official archive) to know that I'm aware of the new Policy
version, that I assert the package conforms with it, and exactly what
changes were needed to bring the package into conformance.
--
\ “[T]he speed of response of the internet will re-introduce us |
`\ to that from which our political systems have separated us for |
_o__) so long, the consequences of our own actions.” —Douglas Adams |
Ben Finney
Reply to: