Warren's Package Naming Proposal - Revision 1
Michael Schwendt
ms-nospam-0306 at arcor.de
Fri Oct 31 17:00:06 UTC 2003
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>
More information about the fedora-devel-list
mailing list