That ole Livna Problem/That ole VLC Problem

[Michael Schwendt]

On 16/01/2008, Les Mikesell wrote:
>

[multiple library versions]

> If different ones are necessary to work, then of course I want different
> ones.  And if they weren't necessary...err.. why did we have this confict?

Even if a library version is included in the base repo, a 3rd party
packager may have the desire to offer the next minor upgrade (or
sometimes a snapshot which is believed to fix a bug) in form of
competing packages. E.g. when an application checks for a minimum
version at build-time and because the app's upstream developers want
it like that. The assumption that "newer is better" is widespread, so
packagers and also many users don't see the need to ship multiple
library versions in parallel, when an update can do, too. Whether such
updates are fully compatible and free of regressions is unknown,
however. And we've had it several times that minor version upgrades
(explicitly without a SONAME change) have been the reason for crashes
and other problems. Further, there may be a repo maintainer who has
packaged libfoo for several years, even before it became part of
Fedora. You need to convince the packager that the need to offer
libfoo is gone and that the possibility to offer an update any time is
gone, too, as it has become much more complicated due to the burden of
having to make all libraries and their -devel packages installable in
parallel. Not even explaining why it must be the 3rd party packager
who must relocate or even rename a library in order to make it coexist
peacefully with the base dist, even if it may be the same version with
more/different/experimental features.

Multiple major versions of a library, on the other hand, are less of a
problem. Provided that they are not put into the same package
namespace where they would upgrade eachother. That namespace, however,
is not as well defined as you might think.

> The process is understood within the fedora packaging project.

It is written policy that compatibility packages are too be avoided as
much as possible. The project wants software to move forward. They
want all upstream developers to adapt to new library APIs instead of
sticking to an old API. That's why library packages are upgraded in
favour of offering multiple versions of a library.

Further, there is no policy that mandates the libfoo$MAJOR naming
scheme for libraries where $MAJOR is the SONAME's major version
number. Only such a policy would create planning-safety for 3rd party
repositories. Packagers may give their library packages arbitrary
names. We have libfoo$MAJOR packages as well as compat-libfoo$MAJOR
packages and even compat-libfoo-devel packages.

> The
> problem is that, by policy in some cases, by law in others, and just by
> not being omnipotent in yet others, they don't include everything people
> want to run within the project.

Software which is subject to patenting or licensing problems is even
another topic.