I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
~spot
"TC" == Tom "spot" Callaway <Tom> writes:
TC> I have added a draft for handling Post Release packages.
It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like:
openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final
Epoch is probably the only way out here unless we allow something nasty.
- J<
Le vendredi 23 mars 2007 à 14:50 -0500, Jason L Tibbitts III a écrit :
"TC" == Tom "spot" Callaway <Tom> writes:
TC> I have added a draft for handling Post Release packages.
It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like:
openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final
Epoch is probably the only way out here unless we allow something
Just proves adding any non-numeric part to versions is a bad idea
Nicolas Mailhot wrote:
Le vendredi 23 mars 2007 à 14:50 -0500, Jason L Tibbitts III a écrit :
> "TC" == Tom "spot" Callaway <Tom> writes:
TC> I have added a draft for handling Post Release packages.
It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like:
openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final
Epoch is probably the only way out here unless we allow something
Just proves adding any non-numeric part to versions is a bad idea
Tom's text implies that if you take that route (alphas in versions) you are sure that the upstream guys are not doing that and that is only a single letter minor differentiator (i.e., it is just a single letter license indicator, a upward moving sequence like a,b,c...).
If that cannot be guaranteed or the string is not that trivial, there is the use of releases similar to what is done for pre-release tags.
Are you suggesting that the text should be more emphatic w.r.t. the risks of taking the first route, perhaps?
Cheers, Fernando
Le vendredi 23 mars 2007 à 16:36 -0400, Fernando Nasser a écrit :
Tom's text implies that if you take that route (alphas in versions) you are sure that the upstream guys are not doing that and that is only a single letter minor differentiator (i.e., it is just a single letter license indicator, a upward moving sequence like a,b,c...).
If that cannot be guaranteed or the string is not that trivial, there is the use of releases similar to what is done for pre-release tags.
Are you suggesting that the text should be more emphatic w.r.t. the risks of taking the first route, perhaps?
We've seen time and time again upstreams do not consider themselves bound by any sanity rule when using letters/words. Any letter part in versions should be a red flag.
On Fri, 2007-03-23 at 14:50 -0500, Jason L Tibbitts III wrote:
"TC" == Tom "spot" Callaway <Tom> writes:
TC> I have added a draft for handling Post Release packages.
It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like:
openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final
Epoch is probably the only way out here unless we allow something nasty.
Note that this particular example would be very cracktastic as we're talking about postrelease tags.. so presumably upstream has already released openssl-0.9.6.
Which is not to say that upstream's twisted numbering scheme won't do *something* unexpected. Which is one reason I'd rather see us use the %{X}.%{alphatag} syntax always. The other reason is that using it always makes things less complicated. Instead of asking::
Is this a prerelease or a postrelease? If postrelease, is upstream likely to use sane numbering? If no, use postrelease scheme If yes, use upstreams version until they screw up one time If prerelease, use prerelease scheme
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
-Toshio
On Fri, 2007-03-23 at 14:18 -0700, Toshio Kuratomi wrote:
Which is not to say that upstream's twisted numbering scheme won't do *something* unexpected. Which is one reason I'd rather see us use the %{X}.%{alphatag} syntax always. The other reason is that using it always makes things less complicated. Instead of asking::
Is this a prerelease or a postrelease? If postrelease, is upstream likely to use sane numbering? If no, use postrelease scheme If yes, use upstreams version until they screw up one time If prerelease, use prerelease scheme
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
I'm not opposed to this. I wonder how many examples of the old model are actually in Fedora.
~spot
On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote:
On Fri, 2007-03-23 at 14:50 -0500, Jason L Tibbitts III wrote:
> "TC" == Tom "spot" Callaway <Tom> writes:
TC> I have added a draft for handling Post Release packages.
It might be worth mentioning what to do when upstream ODs on the crackrock and unexpectedly changes to a non-ordered versioning scheme in the middle of a sequence. Something like:
openssl-0.9.6g openssl-0.9.6h openssl-0.9.6final
Epoch is probably the only way out here unless we allow something nasty.
Note that this particular example would be very cracktastic as we're talking about postrelease tags.. so presumably upstream has already released openssl-0.9.6.
Which is not to say that upstream's twisted numbering scheme won't do *something* unexpected.
That's true for purely numerical schemes as well. Looking at perl and perl modules a rpm packager gets head-aches.
Which is one reason I'd rather see us use the %{X}.%{alphatag} syntax always. The other reason is that using it always makes things less complicated. Instead of asking::
Is this a prerelease or a postrelease? If postrelease, is upstream likely to use sane numbering? If no, use postrelease scheme If yes, use upstreams version until they screw up one time If prerelease, use prerelease scheme
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
The point is that we don't really want too many of the prereleases and therefore don't care about the (temporary) obfuscation that much (not that we could do anything better anyway).
But with "postreleases" it's quite different. openssl is a prominent example where people will be confused to see openssl-0.9.8-8.3.b.fc6 instead of what we currently have: openssl-0.9.8b-8.3.fc6.
Other prominent or not so prominent examples I find on my system are openssh-4.3p2-14.fc6, libjpeg-6b-37, automake14-1.4p6-13, flex-2.5.4a-41.fc6, tzdata-2007c-1.fc6, ntp-4.2.4p0-1.fc6, setuptools-0.6c2-5.fc6.at, man-1.6d-2.fc6, libcdaudio-0.99.12p2-8.fc6.at.
I agree that letters in versioning are a bad thing, but we should try to get that done upstream, and try to stick as much as technically sane to upstream versioning (e.g. epochs are not considered sane in this context).
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> I agree that letters in versioning are a bad thing, but we should AT> try to get that done upstream, and try to stick as much as AT> technically sane to upstream versioning (e.g. epochs are not AT> considered sane in this context).
I don't disagree, but if we're going to say that packagers should use alphanumeric versioning when there's a reasonable expectation that it will remain sanely ordered, we should at least give some thought as to what to recommend in the case that upstream decides to abandon sanity.
Epochs are the default out here, I think. In some situations there may be other outs. In a related case I've advocated using a version like "1.2release" when a packager disliked Epoch:, ignored the guidelines, used a version like "1.2beta2", and got stuck. Not terribly pretty, but it only has to last until the next version bump whereas Epoch is forever.
Anyway, I don't want to derail the discussion, and I agree with what's in the draft. We can add additional advice as necessary.
- J<
Le samedi 24 mars 2007 à 01:52 +0100, Axel Thimm a écrit :
On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote:
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
The point is that we don't really want too many of the prereleases and therefore don't care about the (temporary) obfuscation that much (not that we could do anything better anyway).
But with "postreleases" it's quite different. openssl is a prominent example where people will be confused to see openssl-0.9.8-8.3.b.fc6 instead of what we currently have: openssl-0.9.8b-8.3.fc6.
IMHO people (both users and packagers) will be confused if we don't follow consistent rules. The "what if we can reasonably expect upstream to be sane" argument has been rejected for pre-releases (and we've forced the java folks to change their rules accordingly) I really don't see why it should apply for post releases
"But we've done differently in the past" is a weak argument. In the past we had incomplete BRs and broken EVR upgrade paths, we changed stuff to fix it, and people weren't confused.
Lastly consistent rules means we can hope to built them in some future rpm version instead of relying on guidelines, now that rpm dev has resumed.
On Sat, Mar 24, 2007 at 01:15:50PM +0100, Nicolas Mailhot wrote:
Le samedi 24 mars 2007 à 01:52 +0100, Axel Thimm a écrit :
On Fri, Mar 23, 2007 at 02:18:33PM -0700, Toshio Kuratomi wrote:
Our rule would be:: Does upstreams version have an alpha tag? If yes, use alphatag versioning.
The point is that we don't really want too many of the prereleases and therefore don't care about the (temporary) obfuscation that much (not that we could do anything better anyway).
But with "postreleases" it's quite different. openssl is a prominent example where people will be confused to see openssl-0.9.8-8.3.b.fc6 instead of what we currently have: openssl-0.9.8b-8.3.fc6.
IMHO people (both users and packagers) will be confused if we don't follow consistent rules. The "what if we can reasonably expect upstream to be sane" argument has been rejected for pre-releases
No, why do you say so? We are promoting upstream to use even/odd schemes or 1.2.99 schemes (for prereleases to 1.3).
If it plays well with rpm, why break it?
"But we've done differently in the past" is a weak argument. In the past we had incomplete BRs and broken EVR upgrade paths, we changed stuff to fix it, and people weren't confused.
Well, consider a dependency on openssl >= 0.9.8b. If the postrelease letter slides into the release then suddenly we need to know about build-ids in comparisons like >= 0.9.8-X.b.
Dependencies force us to leave the versioning rather uncumbered.
Lastly consistent rules means we can hope to built them in some future rpm version instead of relying on guidelines, now that rpm dev has resumed.
I don't think the rpmvercmp will ever change, no matter how active rpm development is. This is being discussed since rpm was born and the point is no matter how you try to adjust to upstream versioning some upstream authors will be clever enough to break any machine ordering scheme.
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
It seems very consistent, and the text is well written. I like it!
--Fernando
On Fri, Mar 23, 2007 at 04:31:24PM -0400, Fernando Nasser wrote:
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
It seems very consistent, and the text is well written. I like it!
+1, if spot is looking for FPC votes.
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
~spot
I would appreciate it if you would argue the case in which upstream uses the tarball like
<name>-<version>-<release>.tar.gz.
One case is ImageMagick, and the other case is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560
Mamoru
On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote:
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
~spot
I would appreciate it if you would argue the case in which upstream uses the tarball like
<name>-<version>-<release>.tar.gz.
One case is ImageMagick, and the other case is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
Ralf
Ralf Corsepius wrote:
On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote:
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
~spot
I would appreciate it if you would argue the case in which upstream uses the tarball like
<name>-<version>-<release>.tar.gz.
One case is ImageMagick, and the other case is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
'-' is not a valid character in an rpm version.
On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote:
Ralf Corsepius wrote:
On Thu, 2007-03-29 at 23:13 +0900, Mamoru Tasaka wrote:
Tom "spot" Callaway wrote:
I have added a draft for handling Post Release packages.
http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
Comments are always welcomed.
~spot
I would appreciate it if you would argue the case in which upstream uses the tarball like
<name>-<version>-<release>.tar.gz.
One case is ImageMagick, and the other case is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230560
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
'-' is not a valid character in an rpm version.
man tr
%define tarvers 1.2.3-4.5.6 %define rpmvers %{expand:%(echo %tarver | tr - _)} Version: %rpmvers
The real issue however is elsewhere: What is the next "upstream version" of a package, after this "version-release"?
Are we talking about snapshots? E.g. gcc-4.1.2-20070123 -> final version: gcc-4.1.2 In this case, using "4.1.2-20070123" as rpmversion would be a mistake.
Or are we just talking about "upstream" using versioning which doesn't fit into rpm's expectations, e.g. xxx-1-20070123 xxx-1-20070210 ... In this case, what I said above would work.
Ralf
Ralf Corsepius wrote:
On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote:
Ralf Corsepius wrote:
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
'-' is not a valid character in an rpm version.
man tr
%define tarvers 1.2.3-4.5.6 %define rpmvers %{expand:%(echo %tarver | tr - _)} Version: %rpmvers
At which point you're no longer using the exact upstream version. You're using something close to it. There are lots of ways to do something close to something. If the tarball is x.y-z, we could do x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) and they'd all look valid. But none of them follow upstream.
I'd argue that using the latter scheme makes it look closest to upstream, which to me is very important if I want to search for a package by version number. I'd still be able to do find -name abc-x.y-z* or a yum search abc-x.y-z and have it work.
Le samedi 31 mars 2007 à 11:08 -0400, Christopher Aillon a écrit :
Ralf Corsepius wrote:
On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote:
Ralf Corsepius wrote:
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
'-' is not a valid character in an rpm version.
man tr
%define tarvers 1.2.3-4.5.6 %define rpmvers %{expand:%(echo %tarver | tr - _)} Version: %rpmvers
At which point you're no longer using the exact upstream version. You're using something close to it. There are lots of ways to do something close to something. If the tarball is x.y-z, we could do x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) and they'd all look valid. But none of them follow upstream.
Please no underscores I dearly hate underscores in versions. Use a dot it you need to (this is actually the right subversion separator)
I'd argue that using the latter scheme makes it look closest to upstream, which to me is very important if I want to search for a package by version number. I'd still be able to do find -name abc-x.y-z* or a yum search abc-x.y-z and have it work.
There are many way we mangle upstream names & versions, you can't expect yum search abc-x.y-z to work anyway. Following upstream is well and good but following distro conventions comes first.
Take ConsoleKit-libs for example. Someone blindly matched upstream. So it's a one-of-a-kind: - people don't find it easily since it's lot matching usual packagename lowercasing (same for the service btw) - it's a pam package but it's not a pam_foo package like the others
(and it's totally broken on x86_64 right now because it's not putting its stuff in /lib64 as it should)
Don't let upstream quirks creep in distro naming please.
Regards,
On Sat, 2007-03-31 at 17:54 +0200, Nicolas Mailhot wrote:
Take ConsoleKit-libs for example. Someone blindly matched upstream. So it's a one-of-a-kind:
You cannot have it both ways. Either you want us to follow the guidelines ("When naming a package, the name should match the upstream tarball or project name from which this software came.") or you want some other rule ("everything lowercase"). Also, if you have a problem with the way David and I packaged ConsoleKit, why don't you talk to us directly, rather than complaining about "somebody" ?
(and it's totally broken on x86_64 right now because it's not putting its stuff in /lib64 as it should)
Which is totally unrelated to the current discussion, no ?
Le samedi 31 mars 2007 à 16:02 -0400, Matthias Clasen a écrit :
On Sat, 2007-03-31 at 17:54 +0200, Nicolas Mailhot wrote:
Take ConsoleKit-libs for example. Someone blindly matched upstream. So it's a one-of-a-kind:
You cannot have it both ways. Either you want us to follow the guidelines ("When naming a package, the name should match the upstream tarball or project name from which this software came.") or you want some other rule ("everything lowercase")
I don't read this as including random casing, and it seems most others packagers didn't. Most projects will uppercase their project name (or even write it all in uppercase) but most packages names are lowercase-only. Do you want this guideline point clarified?
Also, if you have a problem with the way David and I packaged ConsoleKit, why don't you talk to us directly, rather than complaining about "somebody" ?
The casing is hugely annoying but not bug material IMHO. It's a good example of what happens when blindly following upstream quirks though
(and it's totally broken on x86_64 right now because it's not putting its stuff in /lib64 as it should)
Which is totally unrelated to the current discussion, no ?
That was a random grumbling because I'm too cheap to open a bug today, and I could not raise people on IRC ;) (though it's not totally unrelated — another example where deviating from the norm in seemingly harmless ways breaks stuff)
-- Nicolas Mailhot
On Sat, Mar 31, 2007 at 11:08:31AM -0400, Christopher Aillon wrote:
Ralf Corsepius wrote:
On Fri, 2007-03-30 at 17:31 -0400, Christopher Aillon wrote:
Ralf Corsepius wrote:
IMO, in such cases the upstream "version-release" should be treated as rpm's "version"
'-' is not a valid character in an rpm version.
man tr
%define tarvers 1.2.3-4.5.6 %define rpmvers %{expand:%(echo %tarver | tr - _)} Version: %rpmvers
At which point you're no longer using the exact upstream version. You're using something close to it. There are lots of ways to do something close to something. If the tarball is x.y-z, we could do x.y_z-1.fc7 (version: x.y_z) or x.y-z.1.fc7 (version x.y release z.1) and they'd all look valid. But none of them follow upstream.
I'd argue that using the latter scheme makes it look closest to upstream,
Yes, but that's already all there is to it. rpm dependencies on minimal/maximal versions get busted or you start polluting the dependencies by parts of the %release tag. It is better to leave the version semantics as far as possible in the %version field. We only deviate from this when the version ordering would get out of place like 1.0rc5 to 1.0 and we don't have a better way to do that in the %version field alone (and epochs != better by definition ;).
For upstream not using proper separators, e.g. using a hyphen, we can and should always embed our own, be it dots or underscores.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Christopher Aillon -
Fernando Nasser -
Jason L Tibbitts III -
Mamoru Tasaka -
Matthias Clasen -
Nicolas Mailhot -
Ralf Corsepius -
Tom Callaway -
Toshio Kuratomi