Re: Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
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.
vorlon@debian.org http://www.debian.org/
Reply to: