On Tue, Aug 23, 2005 at 07:49:23PM +0900, Simon Horman [Horms] wrote: > long time no see. It seems that the problem is indeed fixed if you get > the sarge (or later) versions of e2fsprogs and glibc. However, some > people don't have that, and its causing some breakage for those people. > Would it be possible for you to add the conflicts that Ted suggested to > the next glibc release. This would seem like a nice way to make the > problem go away for everyone.
Hmm, OK. This is how I understand the problem. If you are using the sarge versions of e2fsprogs (1.37-2sarge1) and libc6 (2.3.2), you're fine. If you are using the latest unstable versions of e2fsprogs (1.38-1 or the just uploaded 1.38-2) and glibc (2.3.5) you're also fine. The problem comes if you are using the sarge (1.37-2sarge1) version of e2fsprogs (or any version of e2fsprogs before 1.37-5) and an unstable version of glibc which is newer than 2.3.4, due to the change in what ldd outputs (the linux-gate.so entry). Since we can't retroactively fix e2fsprogs (although I suppose I am trying to get an updated 1.37-2sarge2 into the next stable update, I could try to convince the release managers to let me get an additional conflicts added, or to get the linux-gate.so filtering added to -2sarge2), the only way to fix this is to add the conflicts line to libc6. On the other hand, do we have to support these kinds of wierd cross-release dependencies? I have in the past updated to an unstable version of libc on a stable system, for various sordid reasons, but I always considered it something hazardous that might break things. I don't know that supporting a mix-and-match between stable and unstable is something we have to do, and if it means adding extra hair into libc6's dependencies that in practice may not get removed for a long time, is it worth doing? Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]