Re: dpkg 188.8.131.52.1 bug
>Carlos Carvalho <email@example.com> writes:
>> dpkg is broken, and libc for x86 is also broken...
>Uh, yeah, right. a) please stop this x86 stuff, it's ia32, m68k and
>probably others, b) what were they meant to do? Break binary
>compatibility in glibc 2.0.x when 2.0.x was deployed? That would be
>good, oh yeah. *narf*
>What was done on ia32/m68k et al. is the only decision that makes
>sense afaics; it allows binary compatibility to be broken at a
>suitable time (i.e. the next major release of glibc, or whatever).
It will break for any libc that has been compiled against 2.1.late
headers on x86/m68k/etc just as it does on alpha today. (Granted,
since 2.1.x isn't stable, this is not yet fatal.)
What should be done is make libc aware of the situtation, and fix
any applications that expect chown() to not follow links. This can
be done without breaking 2.0 kernels. It can, unfortunately, not
be done without breaking compatibility for programs which expect
chown() not to follow links, but since they will break sooner or
later anyway, it is IMHO better to break them on a development
For this particular case, after all fixes are done, you will on a
2.1.late kernel need a dpkg >= whatever version uses lchown().
That dpkg will in turn require a libc6 >= whatever version
implements the workaround for existance/nonexistanse of lchown().
-- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist | Mud at Kingdoms | firstname.lastname@example.org
NetGuide Scandinavia | telnet kingdoms.se 1812 | Fax: +46 31 50 79 39
http://www.netg.se | | Tel: +46 31 50 79 40
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org