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 _______________________________________________ Packman mailing list [email protected] http://212.112.227.138/cgi-bin/mailman/listinfo/packman
