Subject: Re: Alphas and libc dependencies

From: Miquel van Smoorenburg <[email-masked]>
Date: Tue, 6 Aug 1996 12:19:09 +0200 (MET DST)

You (Ian Jackson) wrote:
> All our (ELF i386 and m68k binary) packages are built to build with a
> dependency on `libc5'.
> 
> The Alpha people are not using the standard Linux libc; instead,
> they're using a version of the GNU libc, with a current major number
> of 0 by the looks of things.

No, at the moment the library is installed as /lib/libc-1.93.so with
major 6 (and a symlink libc.so.6 to it). It also has numerous other
little shared libs in /usr/lib..

> As far as I can see we have two ways we can solve this problem:
> 
> 1. Come up with some kind of scheme, more or less formal, for
> modifying these dependencies at build-time.  At one extreme, the alpha
> distribution builders write a wrapper around dpkg-deb which fixes up
> the dependencies.  At the other we come up with an automatic scheme
> for determining shared library dependencies (this will be hard work).

This is ugly, but could be done.

> 2a. Give the package containing our version of glibc version 0 the
> name libc5.  2b. Implement version numbers for virtual packages so
> that we can use one here.

I think 2b should be done; I've built glibc on our alpha, and dpkg, ncurses,
perl etc. I tried letting libc "provide" other packages like:

Provides: elf-libc, libc5, ldso, timezone, libdb1, libgdbm1
Description: The GNU C library version 6 (run-time libraries).

Yes, all this stuff is built from glibc. Most of these are base packages
so that's no problem. Anyway if this would work:

Provides: libc5_5.2.18-8, ldso_ 1.7.14-4, timezone_7.48-3, libdb1_1.85.2-8, libgdbm1_1.7.3-11

it would solve a huge problem.

> I understand that the plan is to eventually merge the Linux and GNU
> libc's, and this'll probably produce a libc6, so whatever solution we
> come up with will only have to last until then.

Would it be very hard to put this in dpkg? Oh and would you like to have
the Alpha patches for dpkg first so you can integrate them into the
normal version (would make it easier for me).

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Tue, 6 Aug 1996 13:32:10 +0200 (MET DST)

> of 0 by the looks of things.

In addition to my last message, here is an alternative I've just though
of. Why don't we just provide dummy (eg empty) libc5, libdb1 etc
packages, and let libc6 depend on them. Then libc5 etc _will_ be
installed..

I think that's what I'll do until Ian has implemented version numbers
for virtual packages (if that's a reasonable solution that is).

Mike.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 9 Aug 96 21:12 BST

> You (Ian Jackson) wrote:
...
> I think 2b should be done;  [...] if this would work:
> 

The problem is that this is quite a significant amount of work, and I
don't really have time to deal with it now.  (Incidentally, the syntax
would be `Provides: libc5 (5.2.18-8), ldso (1.7.14-4)' &c.)

...
> normal version (would make it easier for me).

Certainly you should send me your patches.  IME architecture patches
fall into two categories: bug fixes where I made a mistake (which I'll
fix straight away if I can, for example by using your supplied patch)
and workarounds for architecture-specific braindamage.  I've had some
problems with the latter and m68k and ELF, and I have to say that I'm
very reluctant to put in `workaround' patches.  You have been warned
:-).

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 9 Aug 96 21:13 BST

> for virtual packages (if that's a reasonable solution that is).

Well, it's not ideal - in particular, it means that you can deinstall
libc6 when you clearly ought not to.

How about doing it the other way around - having an empty libc5
package which depends on libc6 ?  This is obviously a bit of a nasty
hack, but it will have the right effect.

Ian.