> Perhaps I did not state this clearly enough. The majority of cases
> I run across are caused by an entirely unnecessary dependancy to
> a version of libc6 which isn't in any way required for the package
> in question. Yes, one can fix this manually. Every time, for every
> package. Which naturally means you do it once or twice and then
> say "oh forget it" and wait a year or whatever until the next stable
> upgrade.
>
> Package Dependencies on lib versions (or any other entity for that
> matter) really are several entirely different things:
>
> * the API changed and my application will fail with any
> lib version prior to this one because it relies on
> the changes.
>
> * bug fixes went into this lib version without which my
> app will crash.
>
> * bug fixes went into this version which I specifically
> want/prefer for my application, but it won't crash
> on the older one.
>
> * I just like to use the latest set of lib version digits
> for no particular reason.
>
> I suspect the majority of package version dependencies fall into
> the last category.
>
> If this was dealt with, there would be a much higher level of
> interoperability between packages in various dists. Still a
> caveat emptor, but far, far easier to deal with.
Is this an example of what you mean?
/usr/sbin/sendmail: /lib/libc.so.6: version `GLIBC_2.3' not found
(required by /usr/sbin/sendmail)
After `apt-get' upgraded sendmail to 8.12.6, this error appeared.
As I recall from another Debian list, the response from whoever
compiled this version was something like "Oops, stuff happens
in the testing distro" but, a month later, there's still no working
replacement. How does one go about fixing this kind of problem?
Andris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
