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 <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org