Mailinglist Archive: opensuse-factory (528 mails)

< Previous Next >
Re: [opensuse-factory] Meeting Minutes Dist Meeting 2007-05-10
  • From: Stanislav Brabec <sbrabec@xxxxxxx>
  • Date: Tue, 22 May 2007 16:05:56 +0200
  • Message-id: <1179842756.18070.8.camel@xxxxxxxxxxxxxx>
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. 

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)? Is it allowed to package development files to
package, which does not have -devel in its name?

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

> 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.

> > > 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.

> > > 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".


Andreas Jaeger wrote:

> There is not yet any tool for automatic collecting of devel 
> > dependencies, but I am thinking about a tool collecting packages
> > from .pc files and #include.
> >
> > Preferred way to do it:
> > Requires:       %{name} = %{version}
> 
> And how can we get rid of these later again?  We currently have a lot of
> packages with too many dependencies ;-(

We need an automatic tool for it. Missing devel dependencies introduces
additional BuildRequires in other packages which are even worse to get
rid.

It is definitely not complicated for .pc files, but more complicated
for .la files and .h files.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@xxxxxxx
Lihovarsk√° 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups