At Wed, 24 Aug 2005 12:46:34 +0900, Horms wrote: > On Tue, Aug 23, 2005 at 08:17:58AM -0400, Theodore Ts'o wrote: > > 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.
Thanks to Simon and Ted with the detailed explanation, I understand what the problem is. > > 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? > > I'm not sure that kind of mixing and matching is really > supported, in the sense that if a new version exists, the > recommended solution is always to upgrade. > > I think your idea is worthwile, as people do mix and match, > but I'll also understand if Goto-san doesn't wan the > extra cruft in control - it will become irrelevant over time. > > I'm going to reassign this bug to libc6, Goto-san can close > it from there in whatever way he sees fit. Thinking about this issue, I agree with Ted's opinion - we don't probably need to consider about cross-release. However, actually this problem was caused by glibc, and such change made old e2fsprogs unusable. It's a bit hard to decide, but in this case I choose to add "Conflicts: e2fsprogs (<= 1.37-2sarge1)". Ted, is this version <= 1.37-2sarge1 correct value? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
