Kevin Fenzi wrote on Fri, 13 Feb 2015 11:36:47 -0700:
On Fri, 13 Feb 2015 15:21:17 +0330
Hedayat Vatankhah <hedayat.fwd@gmail.com> wrote:

<...>
But the thing is, it's really difficult to get right details about the
new package. Forget to change a name somewhere or a provides or
obsoletes. People mess this up all the time. 
I'm not sure if things will be (much) worse than the current situation. Maintainers already do maintain multiple versions of the same library, and also the upgrade path from a Fedora release to the next should work. My assumption was that the effort needed to properly package libfoo3 for F21, is not more than what is already needed when you package it for Rawhide/F22.

Also, this would vary library to library. Some things change slowly and
only support 1 release, some things (cough *ffmpeg*) change version
every release. So in some cases 3 is too many, and in others not
enough. 
Certainly. 3 was a typical example. Having less versions is certainly OK. A maintainer can provide more than 3 versions if he wish, but he might stick to 3 versions. e.g. If he expects the library to change versions too early, he might skip some versions: package libfoo2 and wait for libfoo4. Also, he might have libfoo2 and libfoo3. When libfoo4 released, he can add it and stop maintaining libfoo3 (no further updates for libfoo3) but actively maintain the default version (libfoo2) and the latest version (libfoo4). He might even jump to libfoo5 if it is available. For the next release, it could have libfoo2 (the 'default' version of the previous release) as compatibility package and libfoo5 as the 'default' version.



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.
So, you would need t move these 'default' provides to different
versions on different branches? Doable, but again, someone could merge
back a change and mess up this, so it sounds pretty delicate.
I don't suggest providing the 'default' version as "Provides:" for the default package. Instead, I suggest having a separate package as 'libfoo' which depends on the 'default' version. The package is very unlikely to change during a Fedora release life cycle, so you rarely merge any changes to it (libfoo depends on libfoo2 in F21, and nothing else). I can't imagine any kind of updates for such a package right now.


...snip...

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
Bad idea. Conflicts are horrible and to be avoided. 

2. Flexible: Provide the possibility of installing multiple -devel 
versions, and a method to select the "default" one, like the 
alternatives system.
More complexity... but also there is: 

3. What we do today: make sure all versions are parallel installable. 
How do we do it exactly? More specifically, what do we do about the 'default' version? The one a typical './configure' should be able to find? Things like these should keep working: looking up the header file of the library (e.g. /usr/include/pcap.h), running the expected config executable (e.g. pcap-config), using pkg-config to find the desired library (pkg-config --libs python, which already works), etc.

Actually, I think we are talking about the same kind of solution. I mentioned alternatives system, but I didn't necessarily mean being able to change the default version by users (while that can be nice also). So, doing something like what python-devel/python3-devel does right now is OK. The default symlinks can be provided by the default (libfoo) package.


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.
So, the gist of the proposal is to avoid reviewing new compat packages? 

Is this really such a burden? 
Yes, I think so. (It also means some changes in other places, like some release engineering changes to create git repositories). I also suggest it to be the default/encouraged packaging schema.

Thanks,
Hedayat