Mailinglist Archive: opensuse-factory (528 mails)

< Previous Next >
Re: [opensuse-factory] Meeting Minutes Dist Meeting 2007-05-10
  • From: Andreas Jaeger <aj@xxxxxxx>
  • Date: Tue, 22 May 2007 14:30:25 +0200
  • Message-id: <hozm3xjb1a.fsf@xxxxxxxxxxxxx>
Stanislav Brabec <sbrabec@xxxxxxx> writes:

> Andreas Jaeger wrote:
>
>> * Shared library policy
>>   see: http://en.opensuse.org/Shared_Library_Packaging_Policy
>
>>   If nobody raises objections, we'll move forward with it and add it to
>>   the packagers manual.
>
>
> I would raise several objection:
>
>
> 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?

>
> 2) Naming of devel package.
>
> This is bad proposal, at least for packages using pkgconfig to refer to
> their libraries. These libraries can use arbitrary soname without
> breaking API (but breaking soname ABI).
>
> Example:
> We have package libgsf with libgsf-1.so.114 and libgsf-1.pc.
>
> Naming package libgsf114-devel is a pure nosense, because:
>
> - If the next version will be named libgsf-1.so.115, libgsf115-devel
>   will most probably conflict with libgsf114-devel anyways.
>
> - Packages searching for API-compatible libgsf114-devel will fail.
>
> - When new branch will be created, it will get name libgsf-2.so.0, so
>   this rule will "upgrade" to libgsf0-devel.
>
> So my proposal:
>
> Shared library package should be named libgsf1_114, but devel package
> should be named libgsf1.
>
> 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.
>
> -devel packages should have another number, which should be deduced from
> pkgconfig name. If we will not do it, similar problem as soname one
> problem will remain for devel packages.
>
> Proposal was sent a year ago:
> If package allows installation of more devel versions at once or we
> decided to provide more conflicting devel packages in one OpenSUSE
> version and pkgconfig files use numbers, which
>
> The proble here is real and we have hacks in Build Service to fix
> version compatibility.
>
> devel package should be named libgsf1, package itself probably
> libgsf1_114.
>
> #!/bin/bash
> function propose_package_name {
>     echo -n $1 | sed 's/[0-9]*$//' 
>     echo $(rpm -ql $1{,-devel} 2>/dev/null | grep '\.pc$' |
>         sed 's/.*[^0-9.]\([0-9.]*\)\.pc/\1/;:1;s/\.0$//;t1;s/\.//g' | sort -u)
> }
> for PACKAGE in "$@" ; do
>     propose_package_name "$PACKAGE"
> done
>
>
> 3) Shared library for more packages.
>
>         - There is no reason why a -devel package cannot provide
>         development
>           files for multiple shared library packages.
>
> Yes, in particular cases there it is:
>
> If shared library packages are: avahi, avahi-glib, avahi-qt3, avahi-qt4
> and you will create only one avahi-devel, you must logically add
> Requires for all four upper mentioned packages. It will unintentionally
> introduce need of installation of qt3-devel and qt4-devel, even if you
> want to compile only against glib.
>
>
> 4) Missing rule: Devel package dependency chain.
>
> Devel package dependency chain should be complete and no package should
> be missing. If you install this package, it must depend on all needed
> packages for pkg-config, libtool, #include and symlink targets.
>
> foo-devel package must require foo, either explicitly or implicitly, if
> it is needed for development.
>
> 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 ;-(

> 5) Missing rule: How to call ldconfig
>
> (It's probably already in packagers manual.)

I hope so ;-)

Andreas
-- 
 Andreas Jaeger, aj@xxxxxxx, http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
< Previous Next >