On Sunday 04 March 2007 06:06, Steve Langasek wrote: > > Could you please confirm that you'd approve a freeze exception > > to fix the shlibs entry for libblkid1? It would require respinning > > the debian-installer images, so I want to make sure it would be > > acceptable before I upload a new set of e2fsprogs packages. > > 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 do agree that just "built against a previous version" would not be an issue, but with D-I this is not the real issue. The issue is that a udeb is included integrally _as a package_ in the initrds. Hope this clarifies my reasoning on this subject. Cheers, FJP
Attachment:
pgp_xES9qEkqu.pgp
Description: PGP signature