This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past.
I don't understand which if any of these guidelines apply to this case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
In particular, what should the Version be? (And while we're at it, what should the Release be?)
Rich.
Richard W.M. Jones schrieb:
This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past.
I don't understand which if any of these guidelines apply to this case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
Not quite. These guidelines are referring to assuring consistency of common upstream pre-release/alpha-/beta- (eg. 1.2.3pre1), upstream post-release/bugfix (e.g. 1.2.3fix1), VCS/date-versioning (e.g. 1.2.3-20081230) schemes with "pure numerical" versioning schemes (e.g. 1.2.3).
In particular, what should the Version be? (And while we're at it, what should the Release be?)
rpm-wise, versions and releases are mere "strings", with complex comparision-operations attached to them.
I.e. there is no requirement to have mere numerical %version-%releases, strings are allowed.
The only restriction is each package's NEVR to be steadily increasing between different versions of a package, wrt. rpm's version comparision operations.
I.e. if I understand your case correctly (upstream using r<N>), you could directly use their version strings as %version and chose %release at your personal preference.
Ralf
Le Mar 13 janvier 2009 13:45, Ralf Corsepius a écrit :
I.e. if I understand your case correctly (upstream using r<N>), you could directly use their version strings as %version and chose
It's probably better to use just <N> in that case as alphanumeric versions tend to bite you sooner or later
Nicolas Mailhot schrieb:
Le Mar 13 janvier 2009 13:45, Ralf Corsepius a écrit :
I.e. if I understand your case correctly (upstream using r<N>), you could directly use their version strings as %version and chose
It's probably better to use just <N> in that case as alphanumeric versions tend to bite you sooner or later
They don't bite you much more than using numerical versions do or using proprietary handcrafted versions which are diverging from upstream.
Ralf
Richard W.M. Jones wrote:
This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past.
Note that the crux of this statement is "at any time in the future". If upstream dies and then is revitalized later and the new project lead starts releasing tarballs, you could need epoch to get out of the versioning scheme you choose. (However, epoch does exist, so it's not like you can't escape).
I don't understand which if any of these guidelines apply to this case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
In particular, what should the Version be? (And while we're at it, what should the Release be?)
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Version: 0 Release: 1.DATEsvnNNN
Version: NNNN Release: 1
Version: rNNNN Release: 1
The first, second, and fourth are reasonably safe in case a new upstream emerges at some point in the future and decides to make releases with version numbers. The third would need an epoch if that were to occur. The first and second will survive if upstream switches to a new version control system which doesn't have release numbers (for instance, git and starts using dates) or has different release numbers (ie, starting over from 1) while the other two could require changes.
The first and second most closely follow the letter of our guidelines (non-numeric version and snapshot package respectively) so they will be least confusing if you get a reviewer who thinks that's important and also will help any packager who takes over from you not make silly mistakes if they don't understand the limitations of the other forms. The first doesn't make you figure out the date which is irrelevant since you're pulling from a released tarball.
The fourth, while closest to what upstream has, includes an alpha character in the version which is something that is explicitly forbidden in the Packaging Guidelines. If you want to use that, we'll need to vote on an amendment to allow it.
-Toshio
Toshio Kuratomi a.badger@gmail.com writes:
The fourth, while closest to what upstream has, includes an alpha character in the version which is something that is explicitly forbidden in the Packaging Guidelines. If you want to use that, we'll need to vote on an amendment to allow it.
Really? Don't expect me to adhere to that guideline when packaging something whose upstream uses a letter in the version number.
regards, tom lane
"TL" == Tom Lane tgl@redhat.com writes:
TL> Really? Don't expect me to adhere to that guideline when TL> packaging something whose upstream uses a letter in the version TL> number.
Really? Don't expect me to adhere to any guideline that I ever happen to disagree with at any point in time, ever. Rules simply don't apply to me, regardless of how well-considered they are.
There, fixed it for you.
- J<
Tom Lane wrote:
Toshio Kuratomi a.badger@gmail.com writes:
The fourth, while closest to what upstream has, includes an alpha character in the version which is something that is explicitly forbidden in the Packaging Guidelines. If you want to use that, we'll need to vote on an amendment to allow it.
Really? Don't expect me to adhere to that guideline when packaging something whose upstream uses a letter in the version number.
Instead of complaining, get it fixed.
1) Figure out what upstream version number has a problem. 2) Write a draft to change the guideline with the justification 3) Put it under PackagingDrafts and list it on the PackagingDrafts/ page.
Alternatively to #2, use your justification to convince someone else to do steps 2+ for you.
-Toshio
Toshio Kuratomi a.badger@gmail.com writes:
Tom Lane wrote:
Really? Don't expect me to adhere to that guideline when packaging something whose upstream uses a letter in the version number.
Instead of complaining, get it fixed.
- Figure out what upstream version number has a problem.
Well, I don't have to look very far: among my own packages I find /home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b
It cannot possibly be a good idea to use something other than the upstream version number in Version --- the ensuing confusion would trump whatever rationale there might be for this guideline.
While I hope that there will soon be a new libjpeg upstream release that uses a more typical m.n type of number, it's folly to imagine that Fedora can dictate upstream version numbering practices.
regards, tom lane
On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote:
Toshio Kuratomi a.badger@gmail.com writes:
Tom Lane wrote:
Really? Don't expect me to adhere to that guideline when packaging something whose upstream uses a letter in the version number.
Instead of complaining, get it fixed.
- Figure out what upstream version number has a problem.
Well, I don't have to look very far: among my own packages I find /home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b
It cannot possibly be a good idea to use something other than the upstream version number in Version --- the ensuing confusion would trump whatever rationale there might be for this guideline.
While I hope that there will soon be a new libjpeg upstream release that uses a more typical m.n type of number, it's folly to imagine that Fedora can dictate upstream version numbering practices.
No one said dictate. You ask to get it fixed, if possible. You cajole, bribe, etc.
It's not like fedora is the only distro impacted by this.
-sv
seth vidal skvidal@fedoraproject.org writes:
On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote:
It cannot possibly be a good idea to use something other than the upstream version number in Version --- the ensuing confusion would trump whatever rationale there might be for this guideline.
While I hope that there will soon be a new libjpeg upstream release that uses a more typical m.n type of number, it's folly to imagine that Fedora can dictate upstream version numbering practices.
No one said dictate. You ask to get it fixed, if possible. You cajole, bribe, etc.
[ shrug... ] If the guideline said "non-numeric versions are bad; if you have such a package, try to persuade upstream to use a saner versioning scheme next time, and here are reasons x, y, and z to persuade them with", I'd be fine with that. As it is, all I see is an arbitrary exercise of power that will have the principal result of confusing users.
The very fine fine print of https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease appears to allow "6b" as a version number under the guise of "post-release packages", so we don't need to have a war about libjpeg in particular. But the whole thing reads to me like an exercise in wishful thinking. It's describing somebody's idea of what version numbering ought to be like, not what upstreams actually use in practice.
regards, tom lane
Le mardi 13 janvier 2009 à 14:16 -0500, Tom Lane a écrit :
The very fine fine print of https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease appears to allow "6b" as a version number under the guise of "post-release packages", so we don't need to have a war about libjpeg in particular. But the whole thing reads to me like an exercise in wishful thinking. It's describing somebody's idea of what version numbering ought to be like, not what upstreams actually use in practice.
It's describing version numbering that people undestand and that will work in rpm.
What's wishful thinking is to think you can drop just any versionning convention in rpm and it will magically process it.
Before this convention was written we had many cases of packagers with the same attitude as you that blindly dropped upstream versions in rpm and where surprised when they upgrade paths didn't work. You can see the traces to this day in packages with insane epoch numbers used to workaround broken versionning.
Nicolas Mailhot nicolas.mailhot@laposte.net writes:
Le mardi 13 janvier 2009 à 14:16 -0500, Tom Lane a écrit :
... But the whole thing reads to me like an exercise in wishful thinking. It's describing somebody's idea of what version numbering ought to be like, not what upstreams actually use in practice.
It's describing version numbering that people undestand and that will work in rpm.
What's wishful thinking is to think you can drop just any versionning convention in rpm and it will magically process it.
No, the wishful thinking is that the Fedora guidelines can issue an edict sans justification and expect that upstreams will start following it. The entire text of this guideline should be replaced by "Try to get your upstream to use a versioning convention that rpm understands", plus a link to some reliable documentation about what it understands.
regards, tom lane
Rex Dieter wrote:
That's a general problem, where to draw the line in including explanations or justifications for said guidelines.
As one who learns best when an issue is understood, rather than just rote learned, I would be all for allowing the guidelines to include discrete "more info" type of links into the wiki. The target page might directly describe the issue/thinking etc, or provide links to the discussion that lead to the guideline, or to other documentation eg rpm manual.
DaveT.
"TL" == Tom Lane tgl@redhat.com writes:
TL> No, the wishful thinking is that the Fedora guidelines can issue TL> an edict sans justification and expect that upstreams will start TL> following it.
We don't expect upstreams to follow Fedora guidelines. We expect Fedora packagers to follow Fedora guidelines. If you can get upstreams to make things easier on you, so much the better. Otherwise, adapt.
- J<
Tom Lane wrote:
But the whole thing reads to me like an exercise in wishful thinking. It's describing somebody's idea of what version numbering ought to be like, not what upstreams actually use in practice.
Your other argument that there can be confusion when using something that is not upstream's version number has validity to it but this does not. There's no attempt by the Guidelines to change upstream's versioning practices, only how to accommodate their versioning practices within the realm of what rpm can handle.
So if you still care, please draft a Guideline change. I'd probably use the user confusion argument as primary justification and propose that epoch be used when versioning problems crop up. Note that much of the information on the page would need to be rewritten to show when epoch should be used if this is the proposal.
-Toshio
Toshio Kuratomi schrieb:
Richard W.M. Jones wrote:
This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11':
http://code.google.com/p/dlfcn-win32/downloads/list
As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past.
Note that the crux of this statement is "at any time in the future". If upstream dies and then is revitalized later and the new project lead starts releasing tarballs, you could need epoch to get out of the versioning scheme you choose. (However, epoch does exist, so it's not like you can't escape).
I don't understand which if any of these guidelines apply to this case:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease
In particular, what should the Version be? (And while we're at it, what should the Release be?)
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Version: 0 Release: 1.DATEsvnNNN
Version: NNNN Release: 1
Version: rNNNN Release: 1
Urgh, ... insane overengineering, IMNSHO.
All you are doing is adding confusion on user-expections on versions strings and avoidable hassle to package maintainers.
Ralf
On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote:
Urgh, ... insane overengineering, IMNSHO.
All you are doing is adding confusion on user-expections on versions strings and avoidable hassle to package maintainers.
It really depends on the case at hand. All of those alternatives have issues (epoch versus not following upstream). Chosing the right one would mean knowing the future, since this is not really easy, letting the maintainer chose one of the possibilities, but in an informed way is, in my opinion, the best.
-- Pat
Patrice Dumas schrieb:
On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote:
Urgh, ... insane overengineering, IMNSHO.
All you are doing is adding confusion on user-expections on versions strings and avoidable hassle to package maintainers.
It really depends on the case at hand. All of those alternatives have issues (epoch versus not following upstream).
Not quite - All "upstream version" -> "rpm EVR" schemes have issues somewhere, no matter which scheme is favored.
Chosing the right one would mean knowing the future,
There is no "everlasting right one", there only are "temporary right ones"
since this is not really easy, letting the maintainer chose one of the possibilities, but in an informed way is, in my opinion, the best.
My view is different: A package's maintainer has to find a reasonable compromise between upstream, user-expectation, ease of maintenance and technical possibilities - Choose bizarre version tags is not helpful to anybody.
Or differently: If upstream chooses alpha-numeric versions, it would be silly to use "integer versions" in Fedora.
Ralf
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
Ignore the Version number for now - I can change that to just be '0' later if necessary.
How about the Release number: Isn't it more correct to use 0.<n>.r<mm> instead of <n>.r<mm>? (I mean, in case upstream decides to use 0 or 0.1 as a real version number later on?)
This is the package: https://bugzilla.redhat.com/show_bug.cgi?id=478640
Rich.
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
How about the Release number: Isn't it more correct to use 0.<n>.r<mm> instead of <n>.r<mm>? (I mean, in case upstream decides to use 0 or 0.1 as a real version number later on?)
The release numbers don't really matter. Much about them is personal preference and personal use-case.
This is the package: https://bugzilla.redhat.com/show_bug.cgi?id=478640
I would reject it due to your choice of version.
Ralf
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Rich.
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream version?
Ralf
On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream version?
I'm just trying to work out the best way to do this. Can you not ask cryptic rhetorical questions and just say why the version and release scheme above, derived from Toshio's one, isn't right.
Rich.
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream version?
I'm just trying to work out the best way to do this. Can you not ask cryptic rhetorical questions
These aren't rhetorical question.
My point are: * There is nothing technically wrong with using this upstream's versioning. * Their versioning fits well in to rpm's versioning.
=> There is no reason to introduce a diverge versioning for your packages.
and just say why the version and release scheme above, derived from Toshio's one, isn't right.
It isn't technically wrong, I simply consider his proposal to be foolish, silly and stupid.
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> It isn't technically wrong, I simply consider his proposal to be RC> foolish, silly and stupid.
Because being insulting is obviously the best way to constructively criticize something.
Look, Ralf, you occasionally have good things to say. But when you write things like the above, you're just not being useful, OK? It's just unwanted noise.
- J<
Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> It isn't technically wrong, I simply consider his proposal to be RC> foolish, silly and stupid.
Because being insulting is obviously the best way to constructively criticize something.
Look, Ralf, you occasionally have good things to say. But when you write things like the above, you're just not being useful, OK?
It's just unwanted noise.
OK, I realize you don't want to be told what you don't want to hear, no matter how silly/stupid/dumb/simple-minded a proposal might be.
Would you have preferred me naming Toshio's proposal as "non-discuss worthy attempt of over-engineering"?
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> OK, I realize you don't want to be told what you don't want to RC> hear, no matter how silly/stupid/dumb/simple-minded a proposal RC> might be.
That's rather comical; you have no idea what my stance on this issue is, yet you choose to argue against me anyway. If you were able to articulate your thoughts in a manner which befits adult discussion, you might even find that I agree with you. Anything is possible, as long as you're willing to actually participate in a manner which reflects the dignity of the people you are debating with.
- J<
Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream version?
Prepending 0.0 before the SVN version would avoid the need for an epoch should upstream decide later on to release numbered versions, even one as low as 0.1. (Though it cannot cover all possible ways upstream might use to number releases.)
Eduardo M KALINOWSKI wrote:
Ralf Corsepius wrote:
Richard W.M. Jones wrote:
On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote:
Richard W.M. Jones wrote:
For the moment I've used:
Version: 0.1 Release: 0.1.r11
What issue are you trying to solve by this choice?
You are not solving anything.
I don't understand what you mean.
Let me turn my question around: Why can't you directly use the upstream version?
Prepending 0.0 before the SVN version would avoid the need for an epoch should upstream decide later on to release numbered versions, even one as low as 0.1.
Correct in case of svn snapshot version.
But this doesn't apply here. This upstream releases releases but call them "r<N>".
(Though it cannot cover all possible ways upstream might use to number releases.)
Correct.
Ralf
On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
Ignore the Version number for now - I can change that to just be '0' later if necessary.
Looks good to me. If version is set to 0, this is the safest choice with regard to avoiding epochs in case upstream changes something afterwards. This is also the numbering that is the most different from upstream, but as long as you are aware of that...
-- Pat
Patrice Dumas wrote:
On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote:
In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN
Thanks ..
For the moment I've used:
Version: 0.1 Release: 0.1.r11
Ignore the Version number for now - I can change that to just be '0' later if necessary.
Looks good to me. If version is set to 0, this is the safest choice with regard to avoiding epochs in case upstream changes something afterwards. This is also the numbering that is the most different from upstream, but as long as you are aware of that...
Rubbish.
People will expect: Requires: xxxx > r11
not Requires: xxxx > 0.1.r11
Ralf
packaging@lists.fedoraproject.org