<html style="direction: ltr;">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
Dear all,<br>
I don't know if this has been discussed before, but I didn't find
any.<br>
<br>
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. <br>
<br>
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).<br>
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.<br>
<br>
Proposal: let's make it possible to have multiple versions of the
same library installed, as far as their .so version permits that. <br>
<br>
1. Include the base version of the library into its package name.
So, instead of libfoo we can have libfoo2, libfoo3, libfoo4. <br>
2. No reviews are required for new libfooX packages (as it is not
required right now when you update your libfoo package).<br>
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. <br>
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.<br>
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. <br>
<br>
For -devel packages, two methods can be allowed:<br>
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<br>
2. Flexible: Provide the possibility of installing multiple -devel
versions, and a method to select the "default" one, like the
alternatives system.<br>
<br>
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.<br>
<br>
Q: Can't a packager do it already? Why propose it as a 'proposal'?<br>
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. <br>
<br>
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. <br>
As a developer, it makes the version of available libraries for
development less bounded to Fedora version.<br>
<br>
Regards,<br>
Hedayat<br>
</body>
</html>