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

RFC: policy supplement for library packages

Hi Folks!

The late discussion here on migration to libc6 indicates that a 
statement on the requirements of library run time and development
packages is to be included in the policy manual. This is how I recall
the discussion we had about this topic some weeks ago. It might be
that I am a little biased, so feel free to correct me if you recall it
differently. Neither is this meant to be a fixed thing but we
definitely _need_ something so I started writing.
As I am taking over libc5 and libc6 from David Engel I will be heavily
involved in this anyway.


    -=-=-=-=-=-=-=-=-=-=-= 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   |   libfoo     | /usr/lib/libfoo.so.<ver>
         libc5   | libfoo-libc5 | /usr/lib/libc5-compat/libfoo.so.<ver>

    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.

    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. 

  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     | libfoo-dev          | /usr/{lib,include}
      libc5     | libfoo-libc5-altdev | /usr/i486-linuxlibc1/{lib,include}

    For the transition time there may be packages based on libc5 which
    use the standard location. These have to conflict with libc6-dev,

      libc5     | libfoo-libc5-dev    | /usr/{lib,include}

    No such packages may be part of Debian 2.0.

   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

   <this needs work still, here some keywords> make libraries

   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 binutil 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 compiler package has to supply a way to make one of the two
   environments the default one. 
   Two ways this can be done are:

    - using /usr/i486-linuxlibc1/bin for the libc5 based gcc. Just by
      prepending this to the path this can be made the default.
      This is the standard way such things are handled for
      cross-compilers but has the disadvantage that each user has to
      do this in order to make this change. As this has better
      flexibility this may be considered a feature, however. 

    - use an update-alternatives scheme to make one the default. This
      could be done by the system administrator once and no user would
      have to make changes to his environment.
      This does, however, not allow a single user to change the
      system-wide default easily for himself.

      As this is a disadvantage of the update-alternatives scheme
      that should be fixed anyway, I do not consider this to be a
      major problem.
      This could be changed by adding support for a private alternative
      directory to update-alternatives if not called by root -- I know
      it is already possible when using --altdir and link names the
      user has permission to modify but it is a little hard to use for a
      non-initiate. By making update-alternatives automagically change
      the default links to links in $HOME/bin and $HOME/man  and using
      a directory $HOME/.alternatives as altdir would make it much
      easier to use.
      Having this, the second scheme is much better IMO.
   Currently gcc uses none of these schemes.
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: