I have been searching the web to see if we have any hard and fast rule on converting the PEP 440 version names into an RPM NVR that will allow correct upgrades when a Python package is released.
In particular in PEP 440 the following ordering is true:
0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 < 0.2.post1
I haven't found any Fedora Packaging rules or otherwise any recommendation on transforming a PEP440 package version number to an RPM NVR.
The first thing that comes to mind is that the above numbers become r respectively:
0.2.dev1 -> name-0.2.0-0.0.dev1 0.2.a1 -> name-0.2.0-0.1.alpha1 0.2.b1 -> name-0.2.0-0.2.beta1 0.2.rc1 -> name-0.2.0-0.3.rc1 0.2.c1 -> name-0.2.0-0.3.rc1 (yes c -> rc here) 0.2 -> name-0.2.0-1 0.2.0 -> name-0.2.0-1 0.2.post1 -> name-0.2.0-1.post1
if any of the packages need bugfixes they would have to append a release number, ie a patch on post1 would result in name-0.2.0-1.post1.1
Does this make sense ? Should it be written down/agreed/discussed anywhere/somewhere else ?
Simo.
"SS" == Simo Sorce simo@redhat.com writes:
SS> I haven't found any Fedora Packaging rules or otherwise any SS> recommendation on transforming a PEP440 package version number to an SS> RPM NVR.
Don't the existing versioning guidelines already cover this, though? I don't see how they fail to do so.
https://fedoraproject.org/wiki/Packaging:Versioning#Non-Numeric_Version_in_R...
Isn't that pretty much what you describe? (Except that in the very last case should be name-0.2.0-2.post1 because the release integer must always increment.)
- J<
On Tue, 2016-08-23 at 14:35 -0500, Jason L Tibbitts III wrote:
"SS" == Simo Sorce simo@redhat.com writes:
SS> I haven't found any Fedora Packaging rules or otherwise any SS> recommendation on transforming a PEP440 package version number to an SS> RPM NVR.
Don't the existing versioning guidelines already cover this, though? I don't see how they fail to do so.
https://fedoraproject.org/wiki/Packaging:Versioning#Non-Numeric_Version_in_R...
Isn't that pretty much what you describe? (Except that in the very last case should be name-0.2.0-2.post1 because the release integer must always increment.)
I was looking for something specific to PEP 440 equivalence/normalization rules, I guess there aren't and there is no interest in being overly prescriptive for this case ?
The common rules do allow me to create packages that will update properly though, and I can certainly figure out my way in the ambiguous cases, so they suffice for the time being.
Simo.
"SS" == Simo Sorce simo@redhat.com writes:
SS> I was looking for something specific to PEP 440 SS> equivalence/normalization rules, I guess there aren't and there is SS> no interest in being overly prescriptive for this case ?
I'm not sure. I mean, if someone wants to write something I don't see how it would hurt, but I'm not sure it wouldn't just repeat what's already there. Maybe just using the python thing as another specific example?
- J<
On Tue, Aug 23, 2016 at 3:25 PM, Simo Sorce simo@redhat.com wrote:
I have been searching the web to see if we have any hard and fast rule on converting the PEP 440 version names into an RPM NVR that will allow correct upgrades when a Python package is released.
In particular in PEP 440 the following ordering is true:
0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 < 0.2.post1
If we were allowed to, I'd probably structure like so in the Version field:
0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 ) < 0.2+post1
To me, this is more natural than doing the weird release hacking we do now.
On Tue, Aug 23, 2016 at 4:11 PM, Neal Gompa ngompa13@gmail.com wrote:
On Tue, Aug 23, 2016 at 3:25 PM, Simo Sorce simo@redhat.com wrote:
I have been searching the web to see if we have any hard and fast rule on converting the PEP 440 version names into an RPM NVR that will allow correct upgrades when a Python package is released.
In particular in PEP 440 the following ordering is true:
0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 < 0.2.post1
If we were allowed to, I'd probably structure like so in the Version field:
0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 ) < 0.2+post1
To me, this is more natural than doing the weird release hacking we do now.
I'd also like to note that this also rather cleanly handles structures like the following:
0.2.dev1+post2 => 0.2~0.dev1+post2
This scheme is possible in all Fedora versions and at least in EL6 and up.
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> 0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 ) NG> < 0.2+post1
We've been over the terrible tilde magic thing already (more than once). It doesn't solve the general problem and hence only adds complexity instead of helping.
- J<
On 08/23/2016 03:25 PM, Simo Sorce wrote:
I have been searching the web to see if we have any hard and fast rule on converting the PEP 440 version names into an RPM NVR that will allow correct upgrades when a Python package is released.
In particular in PEP 440 the following ordering is true:
0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 < 0.2.post1
I haven't found any Fedora Packaging rules or otherwise any recommendation on transforming a PEP440 package version number to an RPM NVR.
The first thing that comes to mind is that the above numbers become r respectively:
0.2.dev1 -> name-0.2.0-0.0.dev1 0.2.a1 -> name-0.2.0-0.1.alpha1 0.2.b1 -> name-0.2.0-0.2.beta1 0.2.rc1 -> name-0.2.0-0.3.rc1 0.2.c1 -> name-0.2.0-0.3.rc1 (yes c -> rc here) 0.2 -> name-0.2.0-1 0.2.0 -> name-0.2.0-1 0.2.post1 -> name-0.2.0-1.post1
if any of the packages need bugfixes they would have to append a release number, ie a patch on post1 would result in name-0.2.0-1.post1.1
Does this make sense ? Should it be written down/agreed/discussed anywhere/somewhere else ?
Isn't this covered by PEP 440 Local Version scheme?
https://www.python.org/dev/peps/pep-0440/#id23
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
John Dennis -
Neal Gompa -
Simo Sorce