[packman] packman repo issues with openSUSE 11.0 continued

[Christian Morales Vega]

Since I don't see a way to receive old messages I copy and paste even
if this will mess with the archive thread layout...

Toni said
> >   file /usr/lib/liboil-0.3.so.0 from install of liboil0-0.3.15-0.pm.1
> > conflicts with file from package liboil-0.3.14-18.1
> >
> > # zyp se -s liboil*
> > Lese installierte Pakete...
> >
> > S | Name                | Typ   | Version       | Architektur | Repository
> > --+---------------------+-------+---------------+-------------+------------
> >------ i | liboil              | Paket | 0.3.14-18.1   | i586        |
> > openSUSE-11.0-FTP
> >
> >   | liboil-devel        | Paket | 0.3.15-0.pm.1 | i586        | Packman
> >   | 11.0 RPMs liboil-devel        | Paket | 0.3.14-18.1   | i586        |
> >   | openSUSE-11.0-FTP liboil-doc          | Paket | 0.3.15-0.pm.1 | i586
> >   |     | Packman 11.0 RPMs liboil-doc          | Paket | 0.3.14-18.1   |
> >   | i586        | openSUSE-11.0-FTP liboil0             | Paket |
> >   | 0.3.15-0.pm.1 | i586        | Packman 11.0 RPMs liboil0-debuginfo   |
> >   | Paket | 0.3.15-0.pm.1 | i586        | Packman 11.0 RPMs
> >   | liboil0-debugsource | Paket | 0.3.15-0.pm.1 | i586        | Packman
> >   | 11.0 RPMs
> >
> > # rpm -q --provides -p
> > /srv/packman/11.0/i586/liboil0-0.3.15-0.pm.1.i586.rpm liboil = 0.3.12
> > liboil-0.3.so.0
> > liboil0 = 0.3.15-0.pm.1
> >
> > liboil0 seem to miss the usual Provides|Obsoletes: liboil lines.
> NO, won't be fixed.
>
> file a bug against the SuSE package, it is NOT following the SuSE-shared
> library policy, they have published now three times a update of the liboil
> package without changing it to fullfill their own policy. I won't add
> everytime a new Provide/Obsolete statement in my package if the SuSE package
> is updated. Sorry. They have stated the policy and we try to follow it...
>
> >   file /usr/lib/libschroedinger-1.0.so.0 from install of
> > libschroedinger0-1.0.5-0.pm.1 conflicts with file from package
> > libschroedinger-1_0-0-1.0.0-2.1
> same here, the SO-name of libschroedinger is 0 so IMHO our package is
> correct. ...
>
> see here for more information on the shared library policy:
> http://en.opensuse.org/Shared_Library_Packaging_Policy

Well, the SO-name is "libschroedinger-1.0.so.0". The policy says the
package should be named: "lib" + $NAME + $NUM.
Then:"[$NAME is formed by cutting off the prefix "lib" and suffix
".so.*" from the SONAME]

- cutting off the prefix "lib" -> schroedinger-1.0.so.0
- cutting off the suffix ".so.*" -> schroedinger-1.0

Then we have "$NUM is equal to the shared library SONAME number"...
"SONAME number" isn't exactly specific, but we can suppose it refers
to the last '0'. And since "[If $NAME ends in a digit, a dash is
inserted between $NAME and $NUM." we end with:
lib + schroedinger-1.0 + (-)0 = libschroedinger-1.0-0. Then openSUSE
changes the dot for an underscore... even if the dot isn't in $NUM
like the policy specifies.

There are even worse cases. What do you do with a soname like
"libOIS-1.2.0.so"? Following the policy it should be in a package
named "libOIS-1.2.0+$NUM"... but what is $NUM is this case?

Since there is no good name for schroedinger I would just follow the
openSUSE name. But something should be done with the policy to clarify
these cases.

The libois package name probably should be changed to libOIS1_2_0.
Packman names it libois1, but I expect an hypotetic new version to
change the SO-name to libOIS-1.2.1.so (and to be really binary
incompatible). Since the "Rationale" section of the policy says they
want to be able to install different versions of the same library at
the same time*, the full number should be used in the package name so
the next version will have a new package name (libOIS1_2_1).

* Yes, RPM allows to install two versions of a package with the same
name, but...