[packman] packman repo issues with openSUSE 11.0 continued

[Toni]

Am Freitag, 3. Oktober 2008 schrieb 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...

I followed your arguments and hopefully the new packages are 
providing/obsoleting the right names.

-- 
have fun
Toni