[Fedora-packaging] [Vote] Multiple version naming overly restrictive

[Toshio Kuratomi]

On Tue, 2007-07-03 at 13:56 -0600, Stephen John Smoogen wrote:
> On 7/3/07, Toshio Kuratomi <a.badger at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070703/e8340938/attachment.sig>