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

RFC: library conventions for libc5 and libc6 in hamm Take 3

Here is a reworked proposal. If there are no complaints against it, it
should be put into the policy manual.
Changes against the last version:
 - fixed the naming messup (g for libc6 ackages, not libc5!!!) and as
   there are packages around using the 'g' convention, I dropped the
   '-g' convention.
 - cleared up the thread-safe section: it surely isn't needed for
   every library to be made thread-safe. However, if a thread-safe
   library exists, it should be used in the debian package.


    -=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-

 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.  Requirements on libraries for Debian 2.0
 4.  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/i486-linuxlibc1/{lib,include}

   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.  Requirements on libraries for Debian 2.0

   Libraries (regardless of which library they're compiled against) need
   to have runtime dependencies on one of libc, libdl or libm to enable
   the shared linker to determin which library to use for a binary.

   In general we want libraries compiled for libc6 to be thread-safe.
   This is, however, not practical or feasible for every library
   package. Making a library thread-safe involves quite a lot of work,
   much of it nontivial. 
   Thread-safe means that the following changes must be made to the
   library packages:

    - compile the library using -D_RENTRANT or -D_THREAD_SAFE
    - there may be no permanent data residing in the library memory that
      can be different for different threads.
      this means in the first place no static or global variables that
      are not in some way protected from access by a different threads
      via mutexes.
    - all write access to files from a library must be both protected
      using some file locking mechanism in addition to using mutexes.
    - at least some library functions must be protected from being
      used at the same time by two threads sharing the same memory
      space. This is done using mutexes. 

   As these usually are all nontrivial changes to a library if it isn't
   thread-safe already (in which case just using -D_RENTRANT should 
   be used in addition to whatever the library uses to support threads),
   I suggest that noone starts doing this without getting in contact with
   the upstream maintainer(s).

   If a library has a thread-safe version, the debian package should
   use this. The performance deficits usually are very small when not
   linking to libpthreads so only if there are serious reasons, the
   debian package may include the non-thread-safe version.

   There will be a list available that lists all libraries part of
   Debian and their current status regarding compliance with these
   standard requirements. This list will be posted regularly to
   debian-devel by Helmut Geyer <Helmut.Geyer@iwr.uni-heidelberg.de>.    

  4.  Requirements on compiler packages

   The compiler and binutils packages have to provide working
   development environments for both C libraries. Basically (that is
   from the compiler standpoint) there is no real difference between
   the two environments, only some paths and automatic definitions
   have to be changed. All this can be done (and is in fact done) by
   supplying a different specs file in a different location. 
   The gcc packages do this as follows:

   The gcc package uses libc6 by default and is installed in /usr/bin.

   The alt-gcc package uses libc5 by default and is located in 
   /usr/i486-linuxlibc1/bin. By prepending this to the path this can
   be made the default.

   These requirements are fulfilled by the current gcc packages.


 [1] the name of a library package often includes the major version
     number of the library. If so, the 'g' should come before this
     number, e.g. libgdbmg1 as package name for the libc6 based
     runtime package for libgdbm.

 [2] The location ../libc5-compat was introduced in the ldso package. As
     ldso is a package on all linus distributions we'll keep it for
     compatibility with other distributons even though 
     /usr/i486-linuxlibc1/lib would be more consistent.

Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de
public PGP key available :           finger geyer@saturn.iwr.uni-heidelberg.de

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: