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 unnecessarily.
Inter-repo wars are going to exist whether or not Fedora chooses to use epoch - they have no bearing on this decision.
Cheers, -- Elliot
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
unnecessarily.
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
Matthias
On Thu, 24 Feb 2005, Matthias Saou wrote:
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.
You're definitely right that there will always be some special cases, and we'll have to deal them on a one-by-one basis. In that particular special case, I'd prefer to use "1.0beta1" as the version.
However, the existence of this special case above doesn't prove that epoch is bad or the wrong way to handle things. It's important to keep the users in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible.
-- Elliot
Elliot Lee wrote :
You're definitely right that there will always be some special cases, and we'll have to deal them on a one-by-one basis. In that particular special case, I'd prefer to use "1.0beta1" as the version.
However, the existence of this special case above doesn't prove that
epoch
is bad or the wrong way to handle things. It's important to keep the
users
in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible.
Sure, but you've got to make the balance with what Ville just posted... ok, I'm probably a bit biased, but just like him, I think that the current "workaround", which is properly documented and easy to follow is definitely worth it. Oh, that and "epochs are a nightmare"... just ask jbj, he's probably seen some of the wildest bug reports ;-)
Matthias
On Thu, Feb 24, 2005 at 02:23:48PM -0500, Elliot Lee wrote:
You're definitely right that there will always be some special cases, and we'll have to deal them on a one-by-one basis. In that particular special case, I'd prefer to use "1.0beta1" as the version.
But of course that sorts after "1.0", meaning that an epoch is required for the final release.
However, the existence of this special case above doesn't prove that epoch is bad or the wrong way to handle things. It's important to keep the users in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible.
But epochs make it even more confusing for "the users", since they're a) arbitrary and b) mostly invisible.
On Thu, 24 Feb 2005, Matthew Miller wrote:
On Thu, Feb 24, 2005 at 02:23:48PM -0500, Elliot Lee wrote:
You're definitely right that there will always be some special cases, and we'll have to deal them on a one-by-one basis. In that particular special case, I'd prefer to use "1.0beta1" as the version.
But of course that sorts after "1.0", meaning that an epoch is required for the final release.
(Yup)
However, the existence of this special case above doesn't prove that epoch is bad or the wrong way to handle things. It's important to keep the users in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible.
But epochs make it even more confusing for "the users", since they're a) arbitrary and b) mostly invisible.
That's a good point. At the same time, if epoch is used correctly, it will be used only to help rpm comparisons along, and in that case being invisible is a benefit.
It's sounding like most people are comfortable with a policy of "Use upstream version in Version:, unless rpm comparisons will get messed up, in which case you should munge the Release: using the guidelines given".
-- Elliot
On Thu, 24 Feb 2005, Elliot Lee wrote:
It's sounding like most people are comfortable with a policy of "Use upstream version in Version:, unless rpm comparisons will get messed up, in which case you should munge the Release: using the guidelines given".
"unless rpm comparisons will get messed up" translates to "if versions have non-numeric data in them" most of the time. Like I said earlier I'm not opposed to allowing alphabets in versions for post-release updates in sane cases like 1.0 -> 1.0a BUT allowing non-numeric stuff in version leaves a wide opening for mistakes, leading to unnecessary epoch inflation. Epochs ARE evil and confusing to users and packagers as well, much more so than munged version-release tags (simply an empirical observation made over the years on various mailing lists).
- Panu -
However, the existence of this special case above doesn't prove that epoch is bad or the wrong way to handle things. It's important to keep the users in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible.
But epochs make it even more confusing for "the users", since they're a) arbitrary and b) mostly invisible.
to be fair- yum lists epochs if they exist and are non-zero.
So a user listing his/her local packages using yum will see them.
they may not know what they mean - but they'll see them.
epoch:ver-rel
-sv
On Thu, Feb 24, 2005 at 09:48:39PM +0200, Ville Skyttä wrote:
On Thu, 2005-02-24 at 14:39 -0500, seth vidal wrote:
to be fair- yum lists epochs if they exist and are non-zero.
Why not just make that: "yum lists epochs". If (none) == 0, show me the 0.
Wasn't there a bug in rpm where (none) != 0 ?
On Fri, 2005-02-25 at 10:30 -0500, seth vidal wrote:
Wasn't there a bug in rpm where (none) != 0 ?
long ago, in the bad old days.
It's still not completely gone. https://bugzilla.redhat.com/143301
let us not speak of it again.
Sorry, couldn't resist :)
On Fri, 2005-02-25 at 21:29 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 10:30 -0500, seth vidal wrote:
Wasn't there a bug in rpm where (none) != 0 ?
long ago, in the bad old days.
It's still not completely gone. https://bugzilla.redhat.com/143301
let us not speak of it again.
Sorry, couldn't resist :)
LALALALA I can't hear you!! LALALALALALALALA
-sv
On Thu, 2005-02-24 at 13:52 -0500, Elliot Lee wrote:
Inter-repo wars are going to exist whether or not Fedora chooses to use epoch - they have no bearing on this decision.
Non-zero epochs are very inconvenient for 3rd party packagers in general, and especially those who need versioned dependencies and try to achieve cross-distro specfiles. It's not only "inter-repo"; think "upstream", non-FOSS vendors etc.
Yeah, those aren't necessarily the primary target group for FC/FE, but we have a simple, documented workaround that does not make our life harder, and certainly does make someone's easier, so why not apply it?
Epochs may also cause nasty surprises even inside a single repository. They just aren't prominent enough.
On Thu, 24 Feb 2005, Ville [ISO-8859-1] Skytt� wrote:
Inter-repo wars are going to exist whether or not Fedora chooses to use epoch - they have no bearing on this decision.
Non-zero epochs are very inconvenient for 3rd party packagers in general, and especially those who need versioned dependencies and try to achieve cross-distro specfiles. It's not only "inter-repo"; think "upstream", non-FOSS vendors etc.
Yeah, those aren't necessarily the primary target group for FC/FE, but we have a simple, documented workaround that does not make our life harder, and certainly does make someone's easier, so why not apply it?
The workaround /does/ make things harder in general: packagers will have to learn it, and users will have to decipher it. Neither of those things are as trivial as they seem - the proposed scheme is obvious to us only because we already understand it.
Epochs may also cause nasty surprises even inside a single repository.
"may" == FUD :-) -- Elliot
On Thu, 2005-02-24 at 14:26 -0500, Elliot Lee wrote:
The workaround /does/ make things harder in general: packagers will have to learn it, and users will have to decipher it. Neither of those things are as trivial as they seem - the proposed scheme is obvious to us only because we already understand it.
I think the proposed scheme is easier to explain to those who seek information how to name the packages than the unpredictability, bugs and wrinkles inherent with Epochs and/or non-numeric stuff in version comparisons. The former is also already documented.
No, I don't like how it "looks" either.
Elliot Lee sopwith@redhat.com writes:
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.
I do not think so; non-zero epochs should be avoided. Instead of, we should fix the non-numeric version numbers once and forever by changing rpmvercmp() (this is inspired by something which I read on the upm maillist but I do not have a link to it):
Introduce a smaller-than-everything delimiter like '~' so that e.g. the following relations will hold:
1.0~a < 1.0 < 1.0a
Advantages are, that it has a clear semantic, it will not break the traditional rpmvercmp() and does not require addition rpm headers. Disadvantages are some uglyness in the naming, that you can not use '~' as a reqular character anymore (I am not aware of any package having this) and that it causes problems with previous rpm versions not knowing this.
That's one of the situations that epoch was created for.
Epochs were acceptably with the previous behavior (missing epoch in comparision means the epoch of the other side). The current behavior (no epoch means epoch 0) makes it impossible to depend on any upstream version. Therefore, non-zero epochs should be avoided.
Enrico
On Tue, 2005-03-01 at 03:06 +0100, Enrico Scholz wrote:
Elliot Lee sopwith@redhat.com writes:
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.
I do not think so; non-zero epochs should be avoided. Instead of, we should fix the non-numeric version numbers once and forever by changing rpmvercmp() (this is inspired by something which I read on the upm maillist but I do not have a link to it):
I don't disagree with this, however, it will require fairly intrusive changes to rpm. You should float this idea past Jeff and see what he thinks of it. If he accepts the idea, and it is implemented in rpm, then we can revisit the Naming Guidelines.
However, until that point, we're stuck with the non-numeric version case for pre-release packages.
This doesn't mean that we encourage Epoch use, far from it. In fact, if followed (and enforced), the non-numeric version case guidelines help prevent the need for Epoch in the majority of cases.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
packaging@lists.fedoraproject.org
-
Chuck Anderson -
Elliot Lee -
Enrico Scholz -
Matthew Miller -
Matthias Saou -
Panu Matilainen -
seth vidal -
Tom Callaway -
Ville Skyttä