Re: libc5/libc6 conflict
> On Sun, 9 Nov 1997, joost witteveen wrote:
>
> > > Ok, this should be a simple problem. I want to keep all development stuff
> > > libc5, but have some libc6 packages. I don't want to use altdev.
> >
> > Why?
>
> Probably because I don't understand altdev. So let me rephrase the
> question. I have standard *-dev packages from bo, and I install just the
> libc5-altdev package, what effects will it have? Will I have to compile
> anything differently? Will I have to upgrade all my other *-dev packages
> to *-altdev packages? I don't want to do the latter.
Well, I think you do have to do that (officially, anyway. Maybe you could
get away with a bit of cheating, though). If you don't want to do that,
(and really want to go on producing libc5 binaries) I think your best
bet is to not install libc6.
> My other question is why can't there be a normal libc5 in bo that doesn't
> conflict with libc6? And, what's the difference between a *-dev and
> *-altdev pacakge?
The difference between *-dev (from bo) and *-altdev (from hamm) is the
location where the headers and libraries are stored. *-dev puts them
in the "normal" places, whereas *-altdev puts them in a special place,
that only the altgcc compiler has been told to look at.
The first question, "why can't there be a normal libc5 that doesn't
conflict with libc6", is somewhat harder to answer. Actually, I think
there could be one, but that would make life really tough on the
library maintainers. I'll try to explain how it's done now, hopefully
that makes it clear why.
the header files for libc6 (/usr/include/*.h etc) are different from the
header files in libc5. So, a compiler has to read different header
files for libc5 or libc6. We cannot do that by saygin that in the
source code one has to do stuff like "#include <stdio-libc5.h>"
(that would mean changing every c programme around), so we have to
tell the compiler itself to search in different directories, and put
the libc5 headers in a special location, where only the "libc5 compiler"
(i.e., altgcc) will look.
This is all very nice, but both the bo libc5-dev and the hamm (libc6)
libc6-dev put their "stdio.h" file in /usr/include (as mandated by many
standards, I'm sure). So, there has to be a mechanism that prevents both
the bo libc5-dev and the hamm libc6-dev to be installed at the same time.
Basically, the idea behind our transition stuff is: Let's try to make the
whole system libc6, as soon as possible. All those libc5 headers in the
wrong places will only cause havoc, so we'll just try to get rid of
them (or move them to there special locations) as soon as possible.
You are seeing the result of that: A desision that is designed to keep
the number of problems (bugs, not-working compiler setups, etc) to a
minimum, at the expence of possible somewhat less flexibility.
But look at it this way: you _are_ still able to do what you want
(install libc6, and create libc5 binaries), it's just that you have to
do somewhat more work than you were hoping to do. And the positive side really
is that our method _works_: we are able to generate both libc5 and libc6
binaries, they are able to be run on one system, and you are able to
install libc5 and libc6 libraries (both dev and shared) on one system.
Also, for the "normal" user (those that use bo and only want to create
libc5 apps, or use hamm and only want to create libc6), our method
adds no extra burden. It's just that people that want to do something
"strange" (hamm system, creating libc5 binaries), that we ask to install
a few more packages than they were hoping to.
(Hope I got most stuff right here, though).
--
joost witteveen, joostje@debian.org
My spamfilter is so good, it correctly catches 90% of incoming spam,
*including* all email from my PhD supervisor.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: