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.
