Mailinglist Archive: opensuse-factory (528 mails)

[Richard Guenther <rguenther@xxxxxxx>]

On Tue, 22 May 2007, Stanislav Brabec wrote:

> Richard Guenther wrote: 
> > On Tue, 22 May 2007, Andreas Jaeger wrote:
> > 
> > > Stanislav Brabec <sbrabec@xxxxxxx> 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 <rguenther@xxxxxxx>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx