Explicit versioning of library names [was Re: package, package2, package3 naming-with-version exploit]

[Toshio Kuratomi]

On Wed, Apr 03, 2013 at 08:07:24AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/28/2013 12:47 PM, Toshio Kuratomi wrote:
> > 
> > Note:  Is this a hypothetical?  I'm unable to find a
> > python-django14 (or other versioned python-django) package build in
> > koji.
> 
> Sorry, I forgot to reply to this. This was discussed on the thread
> http://lists.fedoraproject.org/pipermail/devel/2013-February/179185.html
> a while ago. The general sense was that we would function as above. I
> then promptly forgot that the package review hadn't yet been finished
> for python-django14.
> 
> I'm about to approve that review, unless this is being deemed
> unacceptable by FPC (though it's not really in the guidelines).
> 
Sorry I didn't catch the details of that when it was originally proposed.

There's currently guidelines that would prevent that:

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name

"[..]One package should use the base name with no versions and all other addons
should note their version in the name."

There is also an unwritten (I think it's unwritten.  A quick search didn't
find it in the guidelines) rule that in Fedora, the current version of the
library carries the base name.  Older libraries carry the version in the name.
(Not relevant to python: libraries which only have their runtime components
carry a compat- prefix as well).  This is related to another unwritten rule,
that Fedora should be shipping the latest versions of libraries and
discarding older versions and software that is unable to port to keep up
The "First" Foundation and the zope-python-2.4 FESCo ruling also tie into
this.  (Unwritten rules unfortunately tend to become matters of connecting
all the precedents rather than pointing at one place where the complete
picture has been summarized :-(

I only know of one package which breaks this rule.  unisonXY.  The reason
for that is that the unison application has an on-wire format that changes
with every release.  In order to interoperate with the unison program
installed on other distributions and releases of Fedora we ship multiple
unison packages all of which contain the version number in their name.
Because the versions must match otherwise the programs are incompatible,
this could be considered a separate program which makes the package naming
make more sense.

Putting on my FPC hat I would note that this is just a clause in a guideline
that hasn't been rediscussed in several years.  You could propose changes to
it and the full FPC could examine it.  However, it is tricky because the FPC
probably doesn't want to weaken the unwritten rule about older libraries
when making changes.  If you are thinking of making a draft, here's some
possibilities:

* Go ahead and have FPC reconsider the unwritten rule or see if they think
  that dropping the "base name with no version" clause would not impact
  that.
* Have the FPC formally add the unwritten rule to the guideline and drop the
  base name exception at the same time.  This would formalize the unwritten
  rule while relaxing one of the clauses that has historically been one of
  the means to support it.
* Have the FPC consider dropping some parts of the unwritten rule which
  would then make the rule about base-package-name contrary to the new
  model for library packaging.

For some of these modifications FPC might ask for guidance or approval from
FESCo.  But I'd send it to FPC first and let the process there identify what
things should go to FESCo instead.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130404/dcc23c43/attachment.sig>