Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
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
Reply to: