Be careful of library updates once freeze happens.
A few days ago I mentioned that I would probably end up uploading a
new version of PAM to experimental rather than unstable. Julian
Gilbey asked why and during that discussion it became obvious that you
want to be fairly careful how you treat libraries and other
depended-on packages once the freeze starts.
Consider the following unfortunate situation. PAM 0.72 gets
frozen--this means that no new uploads of PAM to unstable will make it
into woody. Shortly there after I finish work on PAM 0.75 and upload
it to unstable. The new libpam0g-dev requires that packages linked
against it depend on the new libpam0g.
Now, there are lots of applications like xdm, libpam-modulename, etc
that link against PAM. Many of these applications are priority
optional/extra. They will freeze later than PAM. If someone builds a
new version of xdm against unstable, it will depend on the new PAM.
This will be enough to keep it out of testing, defeating a significant
part of the point of multi-tiered freezes.
The builder might be able to be clever on their own arch by building
against a frozen libpam, but we have autobuilders and such tricks tend
not to work.
If you maintain a library package that is frozen, you want to be
careful not to upload anything that tightens your shlibdeps until
after the woody release. There are probably other ways of getting the
same problem to happen that do not involve libraries, but they are
probably not as common.
Julian suggested that I bring this up here for discussion/warning.
Reply to: