I'd like to propose change in naming guidelines for multiple packages with same name [1]. It seems to be very common recently, that Fedora carries more than one version of package. Nice example might be Gtk, Qt, Python, db4 [2] and most recently, there are ongoing discussion about Puppet 3 [3] and Guile [4].
In this light, I'd like to see naming guidelines updated in a sense, that the nonversioned package must always be the most recent one.
Here are few examples, how the mentioned packages should be named according to the proposal:
Python: python-2.7.3 -> python2-2.7.3 python3-3.3.0 -> python-3.3.0
Gtk: gtk3-3.6 -> gtk-3.6 gtk2-2.24 -> gtk2-2.24
Qt: - Qt already does this correctly, since qt4 is just virtual provide, hopefully they'll do the same for Qt5 qt -> qt qt3 -> qt3
Puppet: puppet-2.7.18 -> puppet-3.0 puppet2-2.7.18 should be introduced if needed.
I understand that this would mean more pain if you'd like to introduce new version of your app/library, but it would help IMO to keep with Fedoras "First". For illustration, let me give you two examples of current situation and situation after this proposal is hypothetical accepted and lets use Puppet for example.
Current scenario: There is puppet-2.7.18 available in Fedora and new puppet3-3.0 is introduced. Current lib/apps, which depends on the puppet-2.7 stays untouched and works as always. They will migrate to puppet 3 in distant future, if ever. Two versions of puppet are maintained forever with unknown security etc.
Proposed scenario: There is puppet-2.7.18 available, but since new puppet is released, the package is migrated to the most recent version (as always). Now we have puppet-3.0 and lots of broken packages, which depends on puppet-2.7.18. All the dependent package maintainers are nagged by broken dependencies. However, there is introduced also puppet2-2.7.18 for backward compatibility (alternatively compat-package, which is to my knowledge nowhere documented as well). So the package maintainers have now 2 options:
1) be lazy and just fix the dependency to puppet2-2.7.18 2) take this breakage as a motivation to migrate to puppet 3
After this point, we have all packages working. puppet2 might be soon be dropped, since there was bigger push to move towards puppet3. Only puppet3 is supported in short while.
IMO, my proposal pushes the community to keep up with the latest version and fosters the "First" F while currently the "don't do anything" is preferred. It is also worth to note, that once there will be introduced puppet3, there is no obvious way how to get rid of the version out of the name, once puppet 4 is out (you can take look on db4 [2] once more to see where it might lead). And may be there will be need for puppet31 in that case, etc? Not nice.
[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name [2] http://lists.fedoraproject.org/pipermail/devel/2012-April/165946.html [3] http://lists.fedoraproject.org/pipermail/devel/2012-October/172822.html [4] http://lists.fedoraproject.org/pipermail/devel/2012-October/172909.html
Sorry for the broken formatting :/
what you propose is the default method of naming in Fedora. Most of the packages that need to have a backwards compatible version do this. However, there are exceptions to this, some per package (python vs python3, the gtk stuff) and some per project (epel). These exceptions have been figured out by the package maintainers and their reviewers and has seemed to work out okay to me.
Some particulars that I know of: python and python3. python3 is promoted upstream as a new language. The interpreter is referenced as /usr/bin/python3. Code that ran on python2 (unless explicitly written with portability between the two versions) needs rewriting to run on python3. So it is inappropriate to have the python3 interpreter take over the python package (at least for the next few years).
Puppet -- AFAICS, the plan is for Fedora to only have a single version of puppet. EPEL is where there may be multiple versions. EPEL is in a tough spot because they need to not break existing installs. That means that they cannot replace puppet-2.x with puppet-3.x... They will have to have a puppet3 package in EPEL6 if they have an upgraded puppet at all. If there was a desire to have a backwards compat version of puppet in Fedora as well, then we should end up with the following packages:
Replying to [comment:2 toshio]:
what you propose is the default method of naming in Fedora.
Great! Then it should be no problem to codify this in guidelines, since there is nothing like this written, otherwise you would point it out already.
Since this is off-topic, I just want to point out that
It doesn't look like to be new language nor upstream claims it: http://www.python.org/dev/peps/pep-0404/#upgrade-path
Not sure if that would be acceptable argument when migration from GCC 4.6 to 4.7 was done and debugging the errors were magnitude harder then conversion of Python scripts, but Python seems to be exceptional, but never mind.
Replying to [comment:3 vondruch]:
Replying to [comment:2 toshio]: what you propose is the default method of naming in Fedora. Great! Then it should be no problem to codify this in guidelines, since there is nothing like this written, otherwise you would point it out already. Okay, now that you know the present parameters, feel free to propose a draft. It should probably fit into this section of the Naming Guidelines:
Okay, now that you know the present parameters, feel free to propose a draft. It should probably fit into this section of the Naming Guidelines:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name
A couple things about your couple things:
Since this is off-topic, I just want to point out that It doesn't look like to be new language nor upstream claims it: http://www.python.org/dev/peps/pep-0404/#upgrade-path If you look at the date of that PEP, it's relatively recent... well after the release of python3. Upstream started talking about python3 being a new language '''years prior''' to its release.
If you look at the date of that PEP, it's relatively recent... well after the release of python3. Upstream started talking about python3 being a new language '''years prior''' to its release.
If you read the title and intro to the very next section, you should see that the Upgrade Path section is a tongue-in-cheek imagining of the situation.
Did anyone '''want''' to have parallel gcc-4.6 and gcc-4.7 stacks? Did they want to compile all libraries with both gcc-4.6 and gcc-4.7 and force applications to be built against one or the other stacks? Did none of the code written for gcc-4.6 run on gcc-4.7 without being rewritten? How many python libraries and applications have you ported from python2 to python3 so that you can gauge how difficult the task is?
Replying to [comment:4 toshio]:
Replying to [comment:3 vondruch]: Replying to [comment:2 toshio]: what you propose is the default method of naming in Fedora. Great! Then it should be no problem to codify this in guidelines, since there is nothing like this written, otherwise you would point it out already. Okay, now that you know the present parameters, feel free to propose a draft. It should probably fit into this section of the Naming Guidelines: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name
Ok, here is the draft (leaving the flame for later):
Always consider to let a nonversioned package to follow an upstream release versions. The other versions of package kept in Fedora for compatibility reasons should be either prefixed by compat- prefix or their name should be suffixed by version string.
For example, lets have in Fedora foo package of version 1.0 (foo-1.0) while upstream releases version 2.0.
Try to avoid foo2-2.0 package as much as possible, since it prevents innovation and make package version irrelevant.
Replying to [comment:5 vondruch]:
Replying to [comment:4 toshio]: Replying to [comment:3 vondruch]: Replying to [comment:2 toshio]: what you propose is the default method of naming in Fedora.
Replying to [comment:3 vondruch]: Replying to [comment:2 toshio]: what you propose is the default method of naming in Fedora.
Replying to [comment:2 toshio]: what you propose is the default method of naming in Fedora.
I disagree with this claim. There is no default method ... there are several ones. What you describe is just one of them (a common one, though).
Ok, here is the draft (leaving the flame for later): Always consider to let a nonversioned package to follow an upstream release versions.
Always consider to let a nonversioned package to follow an upstream release versions.
The "unversioned package" usually is just a short-cut to the "default version". In most cases it matches with "upstream's spearhead version", but there also are situations where this does not apply, e.g. because the upstream spearhead version is too unstable or too API/ABI incompatible in comparision to preceeding versions.
An example for such a case in Fedora 17 would be "python" (python-2.7.x).
The other versions of package kept in Fedora for compatibility reasons should be either prefixed by compat- prefix or their name should be suffixed by version string. For example, lets have in Fedora foo package of version 1.0 (foo-1.0) while upstream releases version 2.0. If you are reasonably sure that the 1.0 version of foo package will be needed just temporary, then update the original package to foo-2.0 and introduce compat-foo-1.0 package.
The other versions of package kept in Fedora for compatibility reasons should be either prefixed by compat- prefix or their name should be suffixed by version string.
You can never be sure. The more an old version of a package is used by other packages and the more incompatible newer versions are, the more likely it is this "temporary" will converge towards "eternity".
[Think about wayland ... X11 was around for decades. Unless wayland provides very evolved X11-compatibility libs, X11 will have to stay for many years (I am inclined to say: measured in decades).]
If there might be more then one older version of library, then migrate the foo-1.0 to foo-2.0 and introduce the compatibility package foo1-1.0 or optionally foo10-1.0 package (the version in name depends on versioning scheme used by upstream). Try to avoid foo2-2.0 package as much as possible, since it prevents innovation and make package version irrelevant.
I do not share this view. To me, using foo2-2.0 means "foo2" is meant to allow parallel installation, in parallel to "foo1 and/or foo3".
This is helpful in situations, when such "parallel installation" cases are known from the beginning.
Ralf, let me clarify. There is always higher rule "use your own good judgement". This proposal was not meant that it is must but it is shuld. So this proposal is trying to motivate people to follow the best practice, not to enforce them. So the wording might be definitely improved.
For the compat- yes, you can never be sure, but it can be either dropped (but still, there are already compat- packages, so it might be clarified) or there might be additional process. Just for example, it might define how long the compat- package stays in Fedora before it will be dropped.
Of course foo2-2.0 is parallel installation, but in my view, there should be always foo-x and foo(x-1)-(x-1). There should never be foo-x and foo(x+1)-(x+1). The parallel case should be avoided as much as possible. That is what we always strive for, to have only one package of some name on the system.
The reason why Python 2.x is still popular is that there is no motivation to move toward Python 3.0. This makes troubles to upstream, since they have to maintain more versions and at the end, it slows down development of python and whole community. This naming convention would be one of motivators how to move forward.
The FPC rejected your draft as written (-5), however, it wishes to note that there is some consensus that an improved, single standard for addressing compatibility and multiple-version-packaging would be desirable, however, your draft does not reflect the wide range of existing cases in Fedora.
The FPC would encourage you (or anyone) willing to tackle the task of rewriting or extending the existing guidelines in this area (http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name) to do so.
Login to comment on this ticket.