/*Kevin Fenzi*/ wrote on Fri, 13 Feb 2015 11:36:47 -0700:
On Fri, 13 Feb 2015 15:21:17 +0330
Hedayat Vatankhah <hedayat....@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
