[Vote] Multiple version naming overly restrictive

[Toshio Kuratomi]

We didn't have quorum in the Fedora Packaging Meeting but we did discuss
the proposal[1]_ to relax the guidelines for packages with multiple
versions.  After some discussion it was decided that restricting the
maintainer too much is not desirable.  Some points:

* Guideline was written in the present manner to avoid confusion
* Using compat-* as a namespace for all less than current libraries has
the following disadvantages over [name][version]:
  * cvs history won't follow the compat-* even though it is arguably
closer to the original package than the upgraded one.
  * BuildRequires would have to be changed between branches to
accommodate the compat-* on the newer branch.

I'd like to have votes on relaxing the guidelines as follows:

'''
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.
'''

This gives the maintainer the leeway to choose whether the package is
best served by having the latest version carry the unadorned name
forward or the previous version.

[1]_:
https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html

-Toshio

[Jesse Keating]

On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote:
>  '''
>  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.
>  '''
>
>  This gives the maintainer the leeway to choose whether the package is
>  best served by having the latest version carry the unadorned name
>  forward or the previous version. 
+1

-- 
Jesse Keating
Release Engineer: Fedora

[Nicolas Mailhot]

Le mardi 03 juillet 2007 à 14:24 -0400, Jesse Keating a écrit :
>  On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote:
>  > '''
>  > 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.
>  > '''
>  >
>  > This gives the maintainer the leeway to choose whether the package is
>  > best served by having the latest version carry the unadorned name
>  > forward or the previous version.
>  
>  +1 
-1

The compat convention is awkward precisely to incite people to converge
on a common version. Making multi-versioning easy is a win short term
and a heavy loss long-term, because everyone just hardcodes a particular
version hoping for "someone else" to clean up the mess.

-- 
Nicolas Mailhot

[Toshio Kuratomi]

On Tue, 2007-07-03 at 21:35 +0200, Nicolas Mailhot wrote:
>  Le mardi 03 juillet 2007 à 14:24 -0400, Jesse Keating a écrit :
>  > On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote:
>  > > '''
>  > > 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.
>  > > '''
>  > >
>  > > This gives the maintainer the leeway to choose whether the package is
>  > > best served by having the latest version carry the unadorned name
>  > > forward or the previous version.
>  > 
>  > +1
>  
>  -1
>  
>  The compat convention is awkward precisely to incite people to converge
>  on a common version. Making multi-versioning easy is a win short term
>  and a heavy loss long-term, because everyone just hardcodes a particular
>  version hoping for "someone else" to clean up the mess.
>   
Possibly.  Note that the current text of the guideline isn't any better.
There is no current guideline to tell when to use (compat-libfoo1 &&
libfoo) vs (libfoo1 && libfoo).

This change just opens up the possibility of libfoo (1.x) and libfoo2
(2.x) being legal.

-Toshio

Multiple version naming overly restrictive

[Axel Thimm]

On Tue, Jul 03, 2007 at 02:24:40PM -0400, Jesse Keating wrote:
>  On Tuesday 03 July 2007 14:16:43 Toshio Kuratomi wrote:
>  > '''
>  > 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.
>  > '''
>  +1 
+1





-- 
Axel.Thimm at ATrpms.net

[Chuck Anderson]

On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote:
>  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.
>  '''
>  
>  This gives the maintainer the leeway to choose whether the package is
>  best served by having the latest version carry the unadorned name
>  forward or the previous version. 
How does this proposal relate to the kernel package?

[Jesse Keating]

On Tuesday 03 July 2007 15:30:24 Chuck Anderson wrote:
>  How does this proposal relate to the kernel package? 
The kernel package succeeds in being able to have multiple versions of it 
installed without changing the name.  None of the files should conflict.

-- 
Jesse Keating
Release Engineer: Fedora

[Tom Callaway]

On Tue, 2007-07-03 at 15:30 -0400, Chuck Anderson wrote:
>  On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote:
>  > 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.
>  > '''
>  > 
>  > This gives the maintainer the leeway to choose whether the package is
>  > best served by having the latest version carry the unadorned name
>  > forward or the previous version.
>  
>  How does this proposal relate to the kernel package? 
fwiw, the kernel is "special" in many ways, but in this case, this would
only affect a hypothetical kernel24 vs kernel.

~spot

[Toshio Kuratomi]

On Tue, 2007-07-03 at 15:30 -0400, Chuck Anderson wrote:
>  On Tue, Jul 03, 2007 at 11:16:43AM -0700, Toshio Kuratomi wrote:
>  > 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.
>  > '''
>  > 
>  > This gives the maintainer the leeway to choose whether the package is
>  > best served by having the latest version carry the unadorned name
>  > forward or the previous version.
>  
>  How does this proposal relate to the kernel package?
>   
It shouldn't.  This proposal deals with package names.  The kernel
doesn't place a version in the package name.

-Toshio

[Stephen John Smoogen]

On 7/3/07, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:
>  We didn't have quorum in the Fedora Packaging Meeting but we did
> discuss
>  the proposal[1]_ to relax the guidelines for packages with multiple
>  versions.  After some discussion it was decided that restricting the
>  maintainer too much is not desirable.  Some points:
>
>  * Guideline was written in the present manner to avoid confusion
>  * Using compat-* as a namespace for all less than current libraries has
>  the following disadvantages over [name][version]:
>    * cvs history won't follow the compat-* even though it is arguably
>  closer to the original package than the upgraded one.
>    * BuildRequires would have to be changed between branches to
>  accommodate the compat-* on the newer branch.
>
>  I'd like to have votes on relaxing the guidelines as follows:
>
>  '''
>  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.
>  '''
>
>  This gives the maintainer the leeway to choose whether the package is
>  best served by having the latest version carry the unadorned name
>  forward or the previous version. 
So I can see this in my head... this would be like

python15
python20
python22
python23
python24
python

for something like say EPEL where you might need to have
python23/24/30 installed on a system for an app to work since the
shipped version is 22. I would say that there would need to be a
standardization of how these older items should/would be packaged up
so that people do not accidently run one when the other was wanted.

Or is this meaning something else?


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Toshio Kuratomi]

On Tue, 2007-07-03 at 13:56 -0600, Stephen John Smoogen wrote:
>  On 7/3/07, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:
>  > We didn't have quorum in the Fedora Packaging Meeting but we did discuss
>  > the proposal[1]_ to relax the guidelines for packages with multiple
>  > versions.  After some discussion it was decided that restricting the
>  > maintainer too much is not desirable.  Some points:
>  >
>  > * Guideline was written in the present manner to avoid confusion
>  > * Using compat-* as a namespace for all less than current libraries has
>  > the following disadvantages over [name][version]:
>  >   * cvs history won't follow the compat-* even though it is arguably
>  > closer to the original package than the upgraded one.
>  >   * BuildRequires would have to be changed between branches to
>  > accommodate the compat-* on the newer branch.
>  >
>  > I'd like to have votes on relaxing the guidelines as follows:
>  >
>  > '''
>  > 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.
>  > '''
>  >
>  > This gives the maintainer the leeway to choose whether the package is
>  > best served by having the latest version carry the unadorned name
>  > forward or the previous version.
>  
>  So I can see this in my head... this would be like
>  
>  python15
>  python20
>  python22
>  python23
>  python24
>  python
>  
>  for something like say EPEL where you might need to have
>  python23/24/30 installed on a system for an app to work since the
>  shipped version is 22. I would say that there would need to be a
>  standardization of how these older items should/would be packaged up
>  so that people do not accidently run one when the other was wanted.
>  
>  Or is this meaning something else?
>   
This change only addresses the naming of such a package, not the
contents.

Your EPEL example is a bit problematic under the old guidelines because,
following the letter of the guideline, [basename][version] that is newer
than [basename] would not be allowed.  So with python-2.3 in RHEL4 a
python15 package would be named appropriately.  python24 would not.

With the new proposal the name python24 would be legal.

-Toshio

[Ville Skyttä]

On Tuesday 03 July 2007, Toshio Kuratomi wrote:
>  '''
>  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.
>  ''' 
+1

[Ralf Corsepius]

On Tue, 2007-07-03 at 11:16 -0700, Toshio Kuratomi wrote:
>  We didn't have quorum in the Fedora Packaging Meeting but we did
> discuss
>  the proposal[1]_ to relax the guidelines for packages with multiple
>  versions.  After some discussion it was decided that restricting the
>  maintainer too much is not desirable. 
ACK.

>  I'd like to have votes on relaxing the guidelines as follows:
>  
>  '''
>  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.
>  ''' 
>  This gives the maintainer the leeway to choose whether the package
> is
>  best served by having the latest version carry the unadorned name
>  forward or the previous version. 
Though consider this proposal to be a step into
the correct direction, I
don't think it goes far enough.

It still recommends "one version package w/ no version". IMO, this
recommendation is more confusing than helpful and should also be
removed. 

[Consider "gtk->gtk2"-like cases: in long term, one can expect gtk to
die out and gtk2 to remain. The recommendation could be interpreted as
recommendation to rename gtk2, then.]

=> +1, but ... proposal: Let's also remove the "no version
recommendation".

Ralf

[Toshio Kuratomi]

On Thu, 2007-07-05 at 11:39 +0200, Ralf Corsepius wrote:
>  On Tue, 2007-07-03 at 11:16 -0700, Toshio Kuratomi wrote:
>  > '''
>  > 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.
>  > '''
>  
>  > This gives the maintainer the leeway to choose whether the package is
>  > best served by having the latest version carry the unadorned name
>  > forward or the previous version.
>  Though consider this proposal to be a step into the correct direction, I
>  don't think it goes far enough.
>  
>  It still recommends "one version package w/ no version". IMO, this
>  recommendation is more confusing than helpful and should also be
>  removed. 
>  
>  [Consider "gtk->gtk2"-like cases: in long term, one can expect gtk to
>  die out and gtk2 to remain. The recommendation could be interpreted as
>  recommendation to rename gtk2, then.]
>  
>  => +1, but ... proposal: Let's also remove the "no version
>  recommendation". 
Okay -- with spot's[1]_ +1 in the earlier thread for the same proposal
and my +1 that's six in favor.  Tentatively approved but need to send it
to FESCo for review now.

Ralf's change makes sense as well.  spot, if you're working on adding
compat-* guidelines, do you want to work this in or should I add it to
next week's agenda separately?  (There's a review pending on this change
so I want to keep the first part moving forward.)

.. [1]
https://www.redhat.com/archives/fedora-packaging/2007-July/msg00013.html

-Toshio

[Tom Callaway]

On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote:

>  Ralf's change makes sense as well.  spot, if you're working
> on adding
>  compat-* guidelines, do you want to work this in or should I add it to
>  next week's agenda separately?  (There's a review pending on this change
>  so I want to keep the first part moving forward.) 
No, go ahead. I don't know when I will get to the compat guidelines.

~spot

[Ralf Corsepius]

On Thu, 2007-07-05 at 11:37 -0500, Tom "spot" Callaway wrote:
>  On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote:
>  
>  > Ralf's change makes sense as well.  spot, if you're working on adding
>  > compat-* guidelines, do you want to work this in or should I add it to
>  > next week's agenda separately?  (There's a review pending on this change
>  > so I want to keep the first part moving forward.)
>  
>  No, go ahead. I don't know when I will get to the compat guidelines. 
The
question to discuss would be: Under which circumstance are they
applicable and when should the <package>N approach be preferred.

I am inclined to think the <package>N approach to be more versatile and
generally applicable (esp. cases of "fully parallel installable
packages"), while the compat-* approach is aiming at providing "backward
compatible run-time packages" (in particular lib-packages).

Ralf

[Tom Callaway]

On Thu, 2007-07-05 at 18:55 +0200, Ralf Corsepius wrote:
>  On Thu, 2007-07-05 at 11:37 -0500, Tom "spot" Callaway
> wrote:
>  > On Thu, 2007-07-05 at 09:25 -0700, Toshio Kuratomi wrote:
>  > 
>  > > Ralf's change makes sense as well.  spot, if you're working on adding
>  > > compat-* guidelines, do you want to work this in or should I add it to
>  > > next week's agenda separately?  (There's a review pending on this
> change
>  > > so I want to keep the first part moving forward.)
>  > 
>  > No, go ahead. I don't know when I will get to the compat guidelines.
>  The question to discuss would be: Under which circumstance are they
>  applicable and when should the <package>N approach be preferred.
>  
>  I am inclined to think the <package>N approach to be more versatile and
>  generally applicable (esp. cases of "fully parallel installable
>  packages"), while the compat-* approach is aiming at providing "backward
>  compatible run-time packages" (in particular lib-packages). 
Yes, I feel the same way. Feel free to draft up text if you are
unwilling to wait for me to get around to it. :)

~spot