[Fedora-packaging] PackageNamingGuidelines comments

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Thu Feb 24 19:18:08 UTC 2005

Elliot Lee wrote :

> Hi guys, I'm late to the party, but overall it looks good.
> The stuff that could improve is eliminating "non-numeric version in
> release". For the sake of keeping things sane and simple, the Version:
> should normally match the upstream version. If there are versions such as
> 0.1beta that compare as "greater than" 0.1, then epoch should be used.
> That's one of the situations that epoch was created for. Making rules
> about munging version & release in the general case, for the sake of
> avoiding epoch in the special case, just complicates things
> Inter-repo wars are going to exist whether or not Fedora chooses to use
> epoch - they have no bearing on this decision.

<evil grin>
So you mean that external repository maintainers like me can't participate
in the discussion or decision? :-)

A bit more seriously, though. I really don't like epoch... Sure, it exists
for the reason you state, but the current guideline is by far the most sane
one we can all agree on, not only for inter-repo compatibility.
For instance, what are you going to do when the package is named 1.0-beta1
(and there are lots like this), as rpm doesn't allow dashes in the version?
You're going to have to do something a bit ugly to your %{version} and
%{source} lines at the least... and in the end, it saves some headaches to
simply use a 0.something release tag for upstream pre-release of a given
%{version} and tuck the details in that "something" part.

What I usually do :

%define prever beta1

Version: 1.0
Release: 0.1.%{prever}
Source: foo-%{version}%{?prever:-%{prever}}.tar.gz

same for %setup line and eventually, but rarely, others


Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3
Load : 0.00 0.17 0.29

More information about the Fedora-packaging mailing list