Dear all,
I don't know if this has been discussed before, but I didn't find any.
Summary: I have a proposal to make it easier for maintainers to have
multiple versions of the same library in distro (by making it
*naturally* possible) (and with minimal maintenance overhead), and for
users/developers to get their desired version(s) installed. Proposal in
brief: instead of packaging libfoo as libfoo, the maintainer *can*
package it as libfooVER (e.g. libfoo2) and create libfoo/libfoo-devel
package which depends on libfoo2/libfoo2-devel. Now, libfoo-3 package
can be packaged as libfoo3, and both can be installed simultaneously
(assuming that they provide different .so versions, otherwise it could
be provided as an update to libfoo2). Notice that once libfoo2 is in the
repos, newer versions (libfoo3/libfoo4) should not require a package
review.
Introduction: As a developer, it happened to me a lot to *wish* my
Fedora version could also have a newer version of libfoo, and I'm not
forced to either upgrade to/wait for the next Fedora release or install
the package just to get a newer version. Also, I've seen many situations
in which I or another user wanted to have multiple versions of the same
library installed (e.g. to run some third party programs).
Currently, this is not possible in Fedora because RPM doesn't allow you
to install multiple versions of the same package (e.g. libfoo). But,
this has been workaround from time to time for some libraries; a good
example is Qt. Qt can't be easily upgraded to version 5 since many
fundamental packages (e.g. KDE) depend on it, but if Fedora didn't
provide Qt5 packages it would be left behind considerably. So, you can
see qt5-* packages in Fedora repository (IIRC, a similar situation has
happened for Qt3->Qt4 upgrade). However, they certainly had to review
all such qt5 packages, and also this is a temporary solution for this
library.
Proposal: let's make it possible to have multiple versions of the same
library installed, as far as their .so version permits that.
1. Include the base version of the library into its package name. So,
instead of libfoo we can have libfoo2, libfoo3, libfoo4.
2. No reviews are required for new libfooX packages (as it is not
required right now when you update your libfoo package).
3. For each Fedora release, there is libfoo/libfoo-devel packages which
Require the "default" version of libfoo packages for that release. For
example, libfoo.fc20/libfoo-devel.fc20 will Require
libfoo2/libfoo2-devel; for F21 libfoo3/libfoo3-devel and for F22/Rawhide
libfoo4/libfoo4-devel.
4. Each Fedora release can provide at least 3 versions of libfoo. e.g.
F21 provides libfoo3 as default libfoo, libfoo2 as compat package, and
libfoo3 as 'latest stable version'. This should not create much burden
for the maintainer, since he is already maintaining these 3 versions for
different Fedora release versions. Now, he can provide all of them in
all active Fedora releases.
5. Packages should either built against the 'default version' (build
requiring libfoo-devel), or the next version if strictly needed.
Building against 'old' version should be discouraged/forbidden. So, in
above example, no F21 packages are allowed to be built against libfoo2,
which is the compatibility libfoo package in F21.
For -devel packages, two methods can be allowed:
1. Simple: -devel packages conflict with each other, so while you can
have multiple versions of libfoo installed, you can have only a single
version of libfoo-devel installed
2. Flexible: Provide the possibility of installing multiple -devel
versions, and a method to select the "default" one, like the
alternatives system.
More details can be discussed, but I think it's enough for now. I want
to see what others think about the whole idea. Details can be worked out
if the idea seems interesting.
Q: Can't a packager do it already? Why propose it as a 'proposal'?
A: Yes, he can, but it'll be hard; mainly because he'll need to put new
versions of the library for review. Also, I suggest it as a 'recommended
practice' for packaging libraries.
IMHO, this method will have many advantages, and can make it much easier
to provide COPR repositories or similar to experiment with new things on
a stable Fedora release without affecting other installed software.
Also, it might make it possible to install and experiment with some
packages from Rawhide/next Fedora release directly on your current release.
As a developer, it makes the version of available libraries for
development less bounded to Fedora version.
Regards,
Hedayat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct