On Tue, 20 Feb 2007, Michael Matz wrote:
> Hi,
>
> On Tue, 20 Feb 2007, Richard Guenther wrote:
>
> > > > /usr/lib64/libxfce4mcs-client.a
> > >
> > > Well, tell the xfce maintainer ;)
> >
> > Seems to be fixed in Factory (I quoted from an installed 10.2 system).
> > Still the .so links are not in the -devel package.
>
> Reminds me of something which we eventually want to have (and which I had
> on my disc since some time): A packaging policy for libraries. I've
> started to cobble up something, though I find my language a bit awkward
> :-/ Anyway, the ideas should become clear.
>
> I haven't yet read the debian library policy, but it certainly is inspired
> by it (via conversation with debian guys). Probably their policy contains
> much more interesting stuff, which might become usable. But let's start
> with something small, and discuss about it.
>
>
> Ciao,
> Michael.
>
> Definitions
>
> lib$NAME.so.* - a shared library, programs can depend on them, usually
> two files exist:
> lib$NAME.so.$MAJOR
> lib$NAME.so.$MAJOR.$MINOR.$MICRO
> lib$NAME.so - file used by link editor (ld) to build executable, usually
> softlink to the shared library file
>
>
> Goal
>
> Enable running old applications needing old shared libraries, without
> recompilation (i.e. by merely copying over some old binary rpms and installing
> them).
>
>
> Library policy
>
> * Shared libs are to be packaged into rpms whose name is
> "lib" + $NAME + $NUM.
> * There is no package containing lib*.so.* files which
> is not named lib$NAME$NUM.rpm.
> * Packages named lib* contain only files named lib*.so.*
> (no headers, no *.so files, no config files, nothing else).
>
> * $NUM contains only decimal digits.
> * $NUM increases strictly with at least the SO version of the
> contained shared libs.
>
> Ideally it corresponds with either the upstream package version or the SO
> version. Example: libfoo.so.1 is packaged in libfoo1.rpm. Or
> libbar.so.3, a part of the program suite PLONK 4.1, would be packaged
> into libplonk41.rpm.
The latter sounds inconsistent. Shouldn't it be named libbar41.rpm? I
would add
* lib$NAME$NUM.rpm either contains exactly one shared library named
lib$NAME.so.* or it contains multiple shared libraries.
* If lib$NAME$NUM.rpm may only contain multiple shared libraries if
the SO versions of all of them change at the same time always. For
convenience library packages should be split if not a dependency
on one shared library automatically creates a dependency on all other
shared library in the package.
* If lib$NAME$NUM.rpm contains multiple shared libraries $NAME should
match the package name. For example if the program blorf.rpm has
libfoo.so.* and libbar.so.* the library package shall be named
libblorf$NUM.rpm
> * All packages named lib* end with $NUM.
Or with -devel.
> * Files needed to develop programs using shared libraries contained in
> lib$NAME$NUM.rpm are packaged in lib$NAME-devel.rpm.
> [??? do we really want to remove $NUM from the -devel rpm?]
That depends on whether multiple -devel versions can be installed in
parallel. Usually this will result in file conflicts with includes
or documentation, so the recommended way is to only have the
latest-and-greatest as lib$NAME-devel. Exceptions allowed.
> Those files include lib*.so, lib*.la and all headers. Optionally those
> files can also be placed in $NAME.rpm, in the case that it also comes
> with other tools or documentation. But _if_ there is a *-devel.rpm
> package then it contains all lib*.{so,la} and headers.
>
>
> Rationale
>
> That scheme makes it possible to install and use multiple shared libraries
> of the same base name, but different so-version (e.g. of older distribution
> in case there are programs requiring them). A discriminator needs to be
> part of the rpm name, as otherwise the update stack will be confused, and
> using some monotonically increasing number as that makes sense. A strict
> structure on rpm names will also help those writing quick&dirty tools.
>
> From that follows that only files should be included therein, which aren't
> generating file conflicts later if installed together with another libbla*
> rpm. Hence only lib*.so.* files are allowed in them. To ensure that no
> shared libraries creep in which aren't handled that way we disallow them
> to be in any package not named via these rules.
>
> Effectively that creates a partition of all files into shared libs and
> others, and makes sure that no rpm contains files from both partitions.
The policy currently misses to talk about static libraries, -fpic issues
and documentation subpackages. A section on ABI compatibility and SO
versions would be nice.
I recommend to have a look at
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
and
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
also the following is a nice checklist for updating packages when
a SO version change is involved.
http://wiki.debian.org/TransitionBestPractices
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
