Re: Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
On Sun, Mar 11, 2007 at 02:22:51AM +0100, Frans Pop wrote:
> On Monday 05 March 2007 10:45, Steve Langasek wrote:
> > > 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?
> My reasoning may be too simple here, but it goes like this:
> - user boots the official installer for Etch
> - has some kind of problem related to e.g. busybox
> - looks in /var/lib/dpkg/status (in the installer)
> - sees busybox version 1:1.1.3-4 was included in the installer
> - goes to packages.d.o and finds only (for example) 1:1.1.3-6
> - gets the original source CD for Etch and finds only 1:1.1.3-6
> So, Debian cannot provide the source that matches the busybox shipped with
> Etch in the installer.
Ok, please explain how this differs substantially from:
- User grabs a package from etch
- has some kind of problem with it
- runs strings on the binary to find that it was built with gcc version
4.1.1ds2-17
- goes to packages.d.o and finds only gcc 4.1.1ds2-21
or:
- User grabs a package from etch
- has some kind of problem with it
- grabs the source and finds that autoconf 2.59 was used to build the
configure script
- goes to packages.d.o and finds only autoconf 2.61-4
These are both cases where there is acknowledged version skew between what
was used for building and what is shipped in the archive at release time,
but the skew is not considered a problem for our source requirement because
there is zero known functional impact. So why is having exactly-matching
versions in /var/lib/dpkg/status any more of a concern?
Now, if there are known functional differences between the two versions in
question, yeah, that kind of skew is a problem -- but that was specifically
not the case we were talking about here.
Cheers,
--
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: