[opensuse-packaging] Shared Library Policy

JP Rosevear

21 Aug 2007 21 Aug '07

20:27

I was packaging a library in the build service, trying out the shared library policy found here: http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy Some thoughts: 1) The "simple" example at the end does not take into account where %doc files should go (AUTHORS, COPYING, README) etc. Suggestion is we say this goes into the lib<whatever><major> package number. Except I just ran into a case where the package had two different .so names 2) No reference to .la files Do we finally want to kill those as a matter of policy? If so, should we write a macro to do it? 3) Separation of soname number from library name We could always put the dash in for more consistency ie libz-1 instead of libz1 so when the library name ends in a number its libwhatever2-7 and its easier for humans to parse (probably). As well libssl is a horrible example to use because it does not follow proper .so naming, it always reflects the version number rather than incrementing based on ABI compatability I'll update the wiki if we can agree on any changes. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Show replies by date

Jan Engelhardt

21 Aug 21 Aug

20:40

On Aug 21 2007 16:27, JP Rosevear wrote:

...

3) Separation of soname number from library name

We could always put the dash in for more consistency ie libz-1 instead of libz1 so when the library name ends in a number its libwhatever2-7 and its easier for humans to parse (probably).

dbus-1-1.0.0-7. So many dashes. I'd even expect some people's tiny scripts breaking if they incorrectly parse numbers from left-to-right. Also, SUSE has had qt3-3.3.7-16, and not qt-3-3.3.7-16 so far :-) I am all for reducing dashes where possible. Jan -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michael Matz

21:05

Hi, On Tue, 21 Aug 2007, JP Rosevear wrote:

...

1) The "simple" example at the end does not take into account where %doc files should go (AUTHORS, COPYING, README) etc.

Suggestion is we say this goes into the lib<whatever><major> package number.

Not if it would generate a file conflict between README of libbla3 and libbla4. The main theme for the whole policy is about packaging shared libraries. It does also provide some best practices, but in general it isn't concerned about where to package documentation. It can be either in the main package (bla), a special docu package (bla-doc), in the -devel package (libbla-devel), or somewhere else. If properly versioned it can theoretically also be placed into the libbla3 packages (e.g. under /usr/share/doc/libbla3/README), but for fear of people getting this wrong (namely placing the files into .../libbla/) I would not mention that in the policy. Currently the policy is quite simple: a libbla<number> rpm contains exactly lib*.so.* files, nothing else. There are already exceptions for this, and exception (3) would also apply to assorted documentation files, so I don't see a pressing need to say something explicit about them.

...

Except I just ran into a case where the package had two different .so names

Split the lib package so that each provides just one library (preferred). Otherwise both libs have to come together from upstream (same tarball for instance, or same CVS module). Then that collection presumably has a name and a version. You can use that as basename and number for the lib package. I would not do that except if they are bound together very tightly, and the version number is increased if one of the sonames is touched.

...

2) No reference to .la files

Do we finally want to kill those as a matter of policy? If so, should we write a macro to do it?

I read this about *.la files in the policy: Package Contents * Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in a -devel package (see (4a) and (4b) for cases that need to version this package). Those files include lib*.so, lib*.la and all headers. ... ... Best Practices ... - Avoid packaging libtool config files (.la files). In general they are not needed if you do not package a static library. If in doubt, ask. So, avoid them if you can (and want to do the work involved). If you don't, then package them into the -devel package. There are very peculiar reasons why sometimes .la files have to be in the libbla3 packages, but that's dealt with in exception (3).

...

3) Separation of soname number from library name

We could always put the dash in for more consistency ie libz-1 instead of libz1 so when the library name ends in a number its libwhatever2-7 and its easier for humans to parse (probably).

I find it easier without the dash actually. But that argument is all about aesthetics, so not a very good one. A better one is perhaps that we have already about 170 lib packages following the policy and most of them are written without the dash (when they can).

...

As well libssl is a horrible example to use because it does not follow proper .so naming, it always reflects the version number rather than incrementing based on ABI compatability

Have a better example? That example is supposed to show what needs to happen if the soname doesn't contain only one number, but several ones (i.e. to show the need for underscores). I fear all other examples doing that have an equally horrifying "scheme" of dealing with so-versions :-) Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Dirk Mueller

22 Aug 22 Aug

08:52

On Tuesday, 21. August 2007, JP Rosevear wrote:

...

1) The "simple" example at the end does not take into account where %doc files should go (AUTHORS, COPYING, README) etc.

not into the library package, no.

...

2) No reference to .la files Do we finally want to kill those as a matter of policy? If so, should we write a macro to do it?

There is a build and a rpmlint check to discover unneccessary .la files, you can kill those. In general killing them is bad is it breaks static linking. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org