Old/compat package naming

[Lubomir Rintel]

Hi,

Alexander pointed out that I was suggesting a wrong name for Saxon 9
package [1]. In fact there's a couple of packages in repositories now
that violate the naming policy [2] in the very same way. Apart from
wondering what does Devrim think about renaming the existing saxon
package, I'm wondering what do others (especially the maintainers of
those other packages) think about renaming their packages?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=532664#c7
[2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_...

The affected packages are these:

antlr           2.7.7-5.fc11
antlr3          3.1.1-7.fc11

automake        1.11-2.fc11
automake17      1.7.9-12

glib            1:1.2.10-32.fc11
glib2           2.20.5-1.fc11

gtk+            1:1.2.10-68.fc11
gtk2            2.16.6-2.fc11

gtksourceview   1:1.8.5-6.fc11
gtksourceview2  2.6.2-1.fc11

junit           3.8.2-5.4.fc11
junit4          4.5-4.1.fc11

Regards,
Lubo

[Bill Nottingham]

Lubomir Rintel ([e-mail]) said:
> glib            1:1.2.10-32.fc11
> glib2           2.20.5-1.fc11
>
> gtk+            1:1.2.10-68.fc11
> gtk2            2.16.6-2.fc11

Given the history of these, this sounds like way more work to change
than it's worth. (They'd certainly have to still provide 'glib2'
and 'gtk2' for many years in the future.)

Bill

[Kevin Kofler]

Bill Nottingham wrote:
> Given the history of these, this sounds like way more work to change
> than it's worth. (They'd certainly have to still provide 'glib2'
> and 'gtk2' for many years in the future.)

Well, given how few things still use gtk+ 1, it shouldn't be that hard to do 
now, as only those things need fixing, for everything using gtk2, a Provides 
is all that's needed (and I'd argue it should be kept there anyway because 
gtk+ should become GTK+ 3 at some point; we're keeping the qt4 and kdelibs4 
Provides permanently for that reason, it makes no sense to remove them and 
change packages to use the unversioned names only to have to change things 
back a few years from now).

Kevin Kofler

[Karsten Hopp]

Am 20.11.2009 17:34, schrieb Lubomir Rintel:
> Hi,
>
> automake        1.11-2.fc11
> automake17      1.7.9-12

What's wrong with this ? automake-1.11 is the new, current version, automake1{4,5,6,7} are the older ones.

Karsten

[Toshio Kuratomi]

On Fri, Nov 20, 2009 at 05:34:40PM +0100, Lubomir Rintel wrote:
> Hi,
>
> Alexander pointed out that I was suggesting a wrong name for Saxon 9
> package [1]. In fact there's a couple of packages in repositories now
> that violate the naming policy [2] in the very same way. Apart from
> wondering what does Devrim think about renaming the existing saxon
> package, I'm wondering what do others (especially the maintainers of
> those other packages) think about renaming their packages?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=532664#c7
> [2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_...
>
> The affected packages are these:
>
> antlr           2.7.7-5.fc11
> antlr3          3.1.1-7.fc11
>
> automake        1.11-2.fc11
> automake17      1.7.9-12
>
> glib            1:1.2.10-32.fc11
> glib2           2.20.5-1.fc11
>
> gtk+            1:1.2.10-68.fc11
> gtk2            2.16.6-2.fc11
>
> gtksourceview   1:1.8.5-6.fc11
> gtksourceview2  2.6.2-1.fc11
>
> junit           3.8.2-5.4.fc11
> junit4          4.5-4.1.fc11

I'm pretty sure this is an incorrect reading of the Guidelines.  The
Guideline itself says:
"""
For many reasons, it is sometimes advantageous to keep multiple versions of
a package in Fedora to be installed simultaneously. When doing so, the
package name should reflect this fact. One package should use the base name
with no versions and all other addons should note their version in the name. 
"""

There's no reason in there that the older package must have the versioning
and the newer package is bare.  I'm pretty sure that that was a specific
discussion point when we worded the Guidelines like that as well.

-Toshio

[Kevin Kofler]

Toshio Kuratomi wrote:
> There's no reason in there that the older package must have the versioning
> and the newer package is bare.

No, but the version almost everyone is going to use should be the default, 
not the suffixed version. Usually, that's the newer version.

Kevin Kofler