Warren's Package Naming Proposal - Revision 1

[Michael Schwendt]

On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:

> >>C-3. Non-Numeric Version to Release
> >>-----------------------------------
> >>As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric
> >>versioned packages can be problematic so they must be treated with care. 
> >> These are cases where the upstream version has letters rather than
> >>simple numbers in their version.  Often they have tags like alpha, beta,
> >>rc, or letters like a and b denoting that it is a version before or
> >>after the number.  Read section B to understand why we cannot simply put
> >>these letters into the version tag.
> >>
> >>Release Tag for Pre-Release Packages:
> >>     0.%{X}.%{alphatag}
> >>Release Tag for Non-Numeric Post-Release Packages:
> >>     %{X}.%{alphatag}
> >>
> >>Where %{X} is the vepoch increment, and %{alphatag} is the string that
> >>came from the version.
> >>
> >>Example (pre-release):
> >>     mozilla-1.4a.tar.gz   from usptream is lower than
> >>     mozilla-1.4.tar.gz    the later "final" version thus
> >>     mozilla-1.4-0.1.a     Fedora package name
> >>
> >>Example (pre-release):
> >>     alsa-lib-0.9.2beta1.tar.gz  becomes
> >>     alsa-lib-0.9.2-0.1.beta1
> >>
> >>Example (post-release):
> >>     gkrellm-2.1.7.tar.gz
> >>     gkrellm-2.1.7a.tar.gz       Quick bugfix release after 2.1.7
> >>     gkrellm-2.1.7-1.a
> > 
> > 
> > For gkrellm is this necessary?  rpm considers 2.1.7a newer than 
> > 2.1.7 already unless something has changed.  Another package of 
> > this nature is UW imap.  It is generally released with an integer 
> > based version number of the year of it's release, possibly 
> > followed by a single letter indicating a revision within that 
> > year.  ie:  imap-2000 imap-2000a imap-2000b
> > 
> > In rpm's normal operation these packages are naturally treated as 
> > the older package on the left, with the newer ones proceeding to 
> > the right.
> > 
> > My personal preference would be to just let rpm assume that as it
> > should work.  I've never gotten bug reports of it not working
> > anyway.  Moving things from the version to the release field
> > unnecessarily just complicates packaging when there's no real
> > benefit IMHO.  For the pre-release cases above it makes sense as
> > it's being done in order to override rpm's default behaviour,
> > which would be to treat what is a final release as older than a
> > prerelease.
> > 
> > I believe treating both pre-release and post-release in the same
> > manner just for consistency with both types of lettered versioned
> > packages is just cosmetic consistency, but doesn't provide any
> > functional or technical benefit.  In other words, sticking with
> > the upstream version in the version field is IMHO best unless
> > there is a technical benefit of doing so, such as avoiding having
> > to later use Epoch to override a prerelease build.
> > 
> > Are there cases where rpm would consider imap-2000a as older than 
> > imap-2000?
> > 
> > jbj?
> >
> 
> Err... you are completely right about it not being necessary in the 
> post-release case.  I am not sure why our fedora.us policy retained that 
> even though it was unnecessary for all these months.  The way I 
> understand the older version of rpm broken rpmvercmp behavior, this 
> wouldn't be a problem with those versions too.

* To be able to go back from 2.1.7a to a patched 2.1.7 in case the
  2.1.7a post-release "fix" turns out to cause side-effects.

* Consistency above all.

* The road of least surprise (with regard to upstream versioning).

* To help avoid that users think foo-1.0a would be an unstable alpha
  version, when in fact it is a post-release patch-level.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031031/b52ea04f/attachment.sig>