Package: debian-policy Summary: Policy should disallow uploads for multiple distributions. Specifically this means same version uploads to "stable unstable". History: Running a buildd, I have the problem of builds that come in for stable and unstable. Currently this means the buildd performs the compile on stable, and either uploads to "stable unstable", or as it were previously, it uploaded to stable, and then asked the buildd admin to perform the same upload to unstable. That used to work, and it used to be a needed feature for "frozen unstable" uploads. We do not support this anymore, since we do not have a "frozen" dist to upload to. Also, dinstall (AKA katie), disallows seperate uploads of the same version to seperate distributions. The pool layout means there is only one copy of the same version, and the pgsql database tracks which distribution this is supposed to be in. It's my opinion that same version uploads to stable/unstable are harful to archive and distribution integrity. I've talked this over with James Troup, and he seems to agree with the points below, and is considering enforcing them via dinstall checks. My intention is to get the weight of policy behind this. Technical reasoning: 1) Building for "stable unstable" means that 99% of the time the build is performed on a box running "stable". So the package will be compiled against "stable" libraries. Now we all know that most of the major libraries will go on to new major versions between releases. Ncurses (4 to 5 between slink and potato), readline (2 to 4 between slink and potato), gnome (several revisions during potato development, and others now), libstdc++ (which changes with the libc6 major upgrades), etc... Now, a lot of libraries keep an oldlib around for backward compatibility of packages that have not been recompiled for the newest version of the lib. This is a less than optimal situation since it must be maintained just like any other package. If libncurses4 is in stable, and libncurses5 is in unstable (with the 4 version around only for backward compat), then builds in unstable should be using the libncurses5. However, someone compiling for "stable unstable" uneedingly prolongs this oldlib's life. 2) Policy changes. This is probably the worst case. We all know that policy abiding build-helpers change between releases just like policy does. Take the usr/doc->usr/share/doc changeover scripts, and the X default scripts used and hardcoded during the build. Building on stable and unstable produces 2 different packages, abiding by two different policies. So by allowing stable built apps into unstable, we prolong policy changes for the distributions aswell. 3) Build failures. It is commonly the case that a package built on stable will not compile on unstable, even though it works runtime wise. Issues: The only issue I forsee is the likely even of where an upload to stable and unstable is desired. I suggest that policy specify this to be done: If package "blah" is in stable/unstable of version 1.0-1 (meaning it has not changed since stable was released) and an upload must be done for both stable and unstable of 1.0-2, then the stable upload must be 1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The reason for the .90 is similar in spirit to how glibc starts a pre-release series (IOW, pre-releases for 2.2 start at 2.1.90). Caveats: This policy in no way forces compiled for unstable to be against the unstable dist. IOW, uploading to unstable does not mean it was compiled against unstable. That is a little harder to enforce. Perhaps we need a way to tell dinstall that certain deps are obsoleted for a dist (IOW, tell dinstall that packages targeted for unstable cannot dep on libncurses4). However, that is another proposal altogether, and is not the aim of this one. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
Attachment:
pgp4FZdJUDDAf.pgp
Description: PGP signature