On Sun, Mar 04, 2007 at 02:15:39PM +0100, Frans Pop wrote: > > It's acceptable to me; the final d-i images haven't been spun yet for > > etch, and anyway a one-line change for a shlibs fix isn't exactly a big > > delta so I don't see a reason to respin even if we did have version > > skew. (I.e., the source requirements are still satisfied for d-i as > > much as they are for any random other package that might happen to be > > built against a previous version of libblkid1, no?)
> Steve, I feel you are missing the point here. The reason I feel it is not > correct to allow packages that build udebs included in any D-I initrd > into Etch after RC2 has been built is as follows. > D-I has package management, including a /var/lib/dpkg/status file. For > udebs that are included in a D-I initrd, the status file in that initrd > lists the exact version of the udebs included when the initrd was built. > So, if you allow new versions into etch after initrds have been built, > there will no longer be a source package available in the distribution > that matches the version listed in the status file. > IMO that would be violation of the source requirements, even if the change > does not affect the udeb. I don't see any reason to think that's a violation of the source requirements. What is the basis for this assertion? Version skew in compilers and gcc has a much greater effect on the contents of packages than this, and we accept such skew as a matter of course. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
