Axel Thimm wrote:
> The reson I use these conventions is because they actually increase
> compatibility: When repo X, repo Y and repo Z (one of them may be
> Fedora, the others two 3rd party ones) have built foo, baz and wuz
> against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
> packages make sure that they can all coexist w/o one repo enforcing a
> full rebuild on the other.
Repos building against different versions of libbar are the actual problem
there. Your solution is a bad attempt at working around it (bad because it
can cause file conflicts between the differently-versioned packages -
library packages are not just a single .so.n file - and is also known to
confuse yum in other situations) which has not been considered useful by
Fedora (as the lack of success of your attempted guideline change shows).
> This will even help Fedora, as the reason Debian/Mandriva introduced
> them was for being able to cope with tons of packages when a
> dependency does an sobump.
In Fedora we already have a solution for that, it's called a mass rebuild.
> Currently in Fedora whenever a package with many dependent other
> packages changes soname, we need to go yelling around to other
> packagers
Which is the right solution. Otherwise the packages will not benefit from
bugfixes and improvements in the new version of the library.
> and are only able to do an upgrade of this kind in rawhide.
No, we can do a grouped update with a library and all dependent packages.
(Buildroot overrides can be requested from rel-eng to build such grouped
updates.) Of course this doesn't make sense for something which almost
everything links, such as OpenSSL, but trying to upgrade such a library in
a release is just insane, it makes much more sense to settle on a single
version. Having packages require different versions of OpenSSL just because
they happened to be built at different times is not helpful, one version is
enough.
> So for Fedora I suggested it w/o looking at 3rd parties, but I'm using
> it at ATrpms for better 3rd party support.
IMHO you should follow the Fedora guidelines on this issue, which means that
you should only add version suffixes for non-default versions of the
library, and only add such non-default (compat or forward-compat) packages
where really needed (and no, "package X in repo Y was not rebuilt against
the new version" is not a real need, it should just get rebuilt; only if
this is not easily possible a compat package makes sense). In addition, the
common practice in Fedora is to use the user-visible version as the suffix,
not the soname version. Otherwise you end up with confusing nonsense such
as KDE 3 libraries in a package called kdelibs4. Sonames are what soname
autoprovs/autoreqs are for, not package names.
> See for example the x264 libs. Any 3rd party repo using them is doomed
> to be incompatible to the other one. Unless we would all use
> libfoo<so> style packaging.
Or unless the smaller repositories (e.g. ATrpms) just accept one large
repository (i.e. RPM Fusion) as the authority for x264 (and again: who was
first is really irrelevant here) and stop shipping incompatible x264
packages. Just build against the version in RPM Fusion. If you don't want
your repository to depend on RPM Fusion (which is IMHO a bad decision),
just re-sign or rebuild the package from RPM Fusion.
> In a nutshell: This is done for better compatibility, not worse.
I know this is the intention, but in practice it is rather unhelpful and
counterproductive. IMHO you should follow the Fedora guidelines closer,
even where you believe them to be technically inferior.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
