[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]

On Sun, Dec 27, 1998 at 10:35:38PM -0600, Gordon Matzigkeit wrote:
>  MB> We would then have libc0.2, libc0.3, libc0.4 etc packages, and
>  MB> binary packages depending on them. We would only maintain one set
>  MB> of development packages. Can you explain the drawbacks of this
>  MB> simple solution?
> Say I have installed libncurses4_4.2-3, which depends on libc0.2.
> What I get from your message is that if we switch to libc0.3, we'll
> just leave libc0.2 installed until we compile libncurses4_4.2-4, so
> that it depends on libc0.3.

> If you make the assumption that everybody using Debian GNU/Hurd will
> be doing a lot of upgrades anyway, then I don't see any real problem
> with that approach.

This is what I thought, too.
> Would you mind explaining in your own words why Debian uses the `g'
> suffix for some packages?  Your message implies that I have somehow
> misunderstood the rationale.  It seems to me that the same reasoning
> you applied here to analysing my plan would also apply to Debian's
> libc5->libc6 upgrade, in which case several packages were renamed when
> they didn't need to be.

Well, I think there are two reasons:

1) We supported both configurations (we actually still do. You CAN _compile_
and run libc5 programs with current Debian systems!). Therefore, we needed
to branch the library packages, because we had two versions all the time.

2) A second reason, which is actually a flaw (but how serious?) in my
proposal is when lib packages are not bumped in the soname:

Consider the following linking:

              <---- bash
glibc 0.2            v
              <---- ncurses 3.4

But when ncurses 3.4 gets recompiled with a new libc:

glibc 0.2     <---- bash
glibc 0.3     <---- ncurses 3.4

... and two different shlibs are in action for the same binary (is my model
actually true? I am just guessing).

This can be bad, and it leads to segfaults with libc5 and libc6. I don't
know if it works for two different libc6 versions, but it does not work for

I think if it is worth a try. If it turns out that we can't do it this way,
we have to fall back to your more complex solution (or anything else what we
come up with). Note that your solution does not scetch out a way how
compiler will be able to find the correct version of a library to link with!

> I'm not looking to blame anybody for gratuitous package
> renaming... I'm just seeking to understand what actually happened
> during the libc5->libc6 upgrade.

I think the main point are above. I append parts of a short document,


 Debian library policy supplement draft for libc5->libc6 migration

   This document is meant to tell what a Debian package providing a
   library should do to support both libc6 (glibc2) and libc5.
   Note that these requirements are for Debian 2.0 (codename hamm).

 1.  Run time packages
 2.  Development packages
 3.  Source packages
 4.  Requirements on libraries for Debian 2.0
 5.  Conflicts and Dependencies
 6.  Handling bugfix releases for Debian 1.3 (bo)
 7.  Requirements on compiler packages

 1. Run time packages

    A package providing a shared library has to support both C library
    packages, libc5 and libc6 based libraries. This must be done using
    two Debian packages, each depending on the correct C library
    The package naming convention currently suggests to name these
    packages as follows. Some packages (mostly from base) may use
    locations in /lib.

       based on  | package name | library location
         libc6   |   libfoog [1]| /usr/lib/libfoo.so.<ver>
         libc5   |   libfoo     | /usr/lib/libc5-compat/libfoo.so.<ver> [2]

    If a library runtime package contains files that are needed by
    both versions of the library, a new package should be made for
    just these files that both other packages depend on.

    This package naming convention does _not_ apply if a package uses
    different sonames for libc5 and libc6 based packages

    There are two exceptions from this rule. The shared linker
    ld-linux.so.1 and the C library files libc.so.5 and libm.so.5
    should still be located in /lib, not in /lib/libc5-compat.

    Packages based on X have to use /usr/X11R6 as prefix, not /usr.
    Note that the X libraries are designed to work with both C libraries.

  2.  Development packages

    The Debian policy requires that all files needed for compiling/linking
    other packages with the library are in a separate package, the
    development package. Up to now this package simply was called
    libfoo-dev. As packages based on libc5 and libc6 usually cannot
    use the same development files there has to be a clear statement
    how to separate these. So for now the following packages are

      based on  | package name        | hierarchy locations
      libc6     | libfoog-dev         | /usr/{lib,include}
      libc5     | libfoo-altdev       | /usr/<a>-linuxlibc1/{lib,include}

   Note that <a> usually is i486, but may not be hardcoded in
   debian/rules. It should be obtained using
        dpkg --print-gnu-build-architecture

   Remember that the libfoo-altdev package has to include symlinks
   /usr/<a>-linuxlibc1/lib/libfoo.so ->
   to enable using the shared libraries when compiling.

   All documentation that is not depending on whether the library was
   compiled for libc5 or for libc6 should be either part of the
   libfoog-dev package or be put into a separate package if it is
   large. In particular this includes manpages which _have_ to be part
   of the libfoog-dev package.

   Note that the choice to base Debian 2.0 on libc6 fixed the fact
   that the main locations will be used for libc6 packages. The
   alternate locations are used for libc5 based packages.
   This decision does not necessarily mean that by default the
   compiler uses the libc6 packages, please read section 4 for more
   information. Using a four-way approach for library locations
   (standard and alternate locations for libc6 and libc5 based
   packages) will make Debian systems inconsistent with each other,
   something we should avoid at (nearly) all costs.

  3. Source packages

   The source package name should _not_ be modified for hamm.

   If a bugfix for bo has to be released, use bo's source package  to
   extract the bo source and add for each hamm release a line to
   debian/changelog stating that this release was a hamm release.
   Make your bugfix changes, including changes to the control file
   according to section 6.

   Then unpack the hamm source again, update debian/changelog and
   debian/control to figure the bo release, and release a new hamm
   package (including the bugfix, if it affects hamm as well). [3]

  5. Conflicts & Dependencies for hamm packages

   The libfoog package _has_ to conflict with all versions of the
   libfoo package before it was made to use the libc5-compat
   directory. Furthermore it should depend on libc6.

   The libfoog-dev package must depend on libc6-dev and the libfoog
   package of the same release. It has to conflict with the libfoo-dev

   The hamm libfoo package has to depend on libc6 and has to conflict
   with libfoo-dev and libc5-dev.

   The libfoo-altdev package has to depend on the libc5-altdev and
   libfoo package of the same release.

"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: