On Tue, 22 May 2007, Stanislav Brabec wrote:

Richard Guenther wrote:

...

On Tue, 22 May 2007, Andreas Jaeger wrote:

...

Stanislav Brabec writes:

...

Andreas Jaeger wrote:

...

* Shared library policy see: http://en.opensuse.org/Shared_Library_Packaging_Policy

...

...

...

0) Static only packages 1) Packages with some devel files in the main package.

If package is static only or package provides devel files (e. g. .pc file) without splitting -devel package, it must provide -devel package, either as a virtual symbol or as a package (by skipping of file list of the main package).

Packages linking against the library or referring devel files from the package (e. g. .pc files), must refer to foo-devel, not foo.

It allows painless move to shared library and painless splitting in future.

Example: package foo with static-only stuff: Provides: %{name}-devel = %{version}-%{release}

Real life example: Package check moved from static to shared library after 10.2. Several other packages were splitted. Both raised need to adopt many other packages.

So, what is your objection here?

I don't get this either. Note the shared libaray naming and packaging policy is about shared libraries, not static ones or naming a -devel (or not -devel) package.

Yes, but it's related. If package changes from static to shared library and the static package was referenced as libfoo, you are in problem: All BuildRequires are now broken.

Huh? If you had a static library only the BuildRequires should have been to FOO-devel. And that may actually have been the only package that existed. Now, at the point you introduce a shared library you simply introduce a lib package for it and be done.

The second mentioned thing can be re-formulated as a missing item in the policy:

Is it allowed to package shared library altogether with development files (.a, .pc, .so, .h)?

No. This is strictly forbidden.

Is it allowed to package development files to package, which does not have -devel in its name?

This should also not be done.

I think that it should not be permitted, even if it causes bigger number of packages. Otherwise it introduces missing devel dependencies (see below).

Sure, but again this is only on the edge of the shlib policy (maybe we shouldn't have added all the words about the non-shlib parts).

...

Shared libraries may reside in /lib{,64} or /usr/lib{,64} only if there are development files packages separately in a -devel package to link against those libraries. See (1) on how to handle different cases.

This looks too strict. There are many packages, which create shared library for more binaries inside one package. What is the benefit to link say metacity binaries with /usr/lib/metacity/libmetacity-private.so.0 instead of /usr/lib/libmetacity-private.so.0? This rule will need additional wirk to change many packages and additional work even to check that all packages conform to this rule.

It avoids polluting the global shlib namespace.

...

...

...

2) Naming of devel package.

...

...

...

So my proposal:

Shared library package should be named libgsf1_114, but devel package should be named libgsf1.

This is exactly what the policy suggests. Where do you read otherwise? Maybe the wording can be improved.

No, it suggests libgsf1_114-devel:

If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package.

Proposed change:

If more than one version of a -devel package can be installed at the same time ... the -devel packages should be suffixed with the same number as the shared library package. If package provides a pkg-config file or another development configuration script or shared library uses epoch number, the -devel packages should be suffixed with the number of it.

I changed it to " If more than one version of a -devel package can be installed at the same time (for example because includes are packaged in a versioned directory and shared libraries have a versioned name like libgtk1.so.1) the -devel packages should be suffixed with a number that allows identifying the version of the library (usually this is the same number as the shared library package suffix $NUM). So such a -devel package would be named lib$NAME$NUM-devel. "

...

...

...

If more than one version of a -devel package can be installed at the same time (for example because includes are packaged in a versioned directory and shared libraries have a versioned name like libgtk1.so.1) the -devel packages should be suffixed with the same number as the shared library package, lib$NAME$NUM-devel.

I see this is a quote from the policy. The wording needs to improve here as $NUM does not suggest a suffix different from $SONAME is allowed.

But it's already part of the policy, last article "Package Naming".

Hm, yes. I'll see to move this sections to a footnote instead and retain "Packages with suffix -devel should in general omit $NUM as -devel packages for different library versions usually conflict due to common header file names." in Package Naming and change the wording in Package Contents to "Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in a -devel package. 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." or did you, above, object to "Optionally those files can also be placed in $NAME.rpm..." especially? Thanks, Richard. -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org