How can packages require a pre-release version?

[Christopher Aillon]

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Vers...

So, this has been a problem for a while for me, but I'm just now getting 
to bring it up...

Basically, packages need to be able to require "xulrunner 2.0 beta 11" 
but that's impossible with the current guidelines...

Essentially, the number that gets incremented is _before_ the 
pre-release, and unfortunately there's no time machine available to 
determine how many increments will occur before the next tarball update, 
so packages can't do
   Require: xulrunner > 2.0-0.19.beta11.fc15
   Require: xulrunner < 2.0-0.22.beta12.fc15

since we might just go straight to 2.0-0.20.beta12.fc15 or we might need 
20 rebuilds of beta 11.  And depending on the specific NVR is suboptimal 
too.

What I want to do for the XULRunner case specifically is change it to:
   xulrunner-2.0-0.0.beta11_1.fc15 // first instance of beta 11
   xulrunner-2.0-0.0.beta11_2.fc15 // rebuild of beta 11
   xulrunner-2.0-0.0.beta11_3.fc15 // another rebuild
   xulrunner-2.0-0.0.beta12_1.fc15 // first instance of beta 12
   xulrunner-2.0-0.0.scm20110209_1.fc15 // scm snap from Feb 9 2011
   xulrunner-2.0-0.1.beta13_1.fc15 // first instance of beta 13

So, the first 0 would signify a pre-release, the second 0 would be used 
as sort of a "prerelease epoch" if needed as shown above, and it would 
be followed by the pre-name, and then a release.  Normally, a hyphen 
would precede the rpm release of a tarball, but we can't have that here 
due to the fact that we're putting some of the version information in 
the release, so I think underscore works just as well here, and is 
better than a dot.

This would allow packages to do things like
   Require: xulrunner >= 2.0-0.0.beta11
   Require: xulrunner <= 2.0-0.0.beta12

Thoughts?


(Note: since we're currently at -0.19... in rawhide, I'd of course start 
with 0.20 for this round of pre-releases, but would start with 0.0 for 
the next set of pre-releases)

[Paul Howarth]

On 10/02/11 02:46, Christopher Aillon wrote:
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Vers...
>
>  So, this has been a problem for a while for me, but I'm just now getting
>  to bring it up...
>
>  Basically, packages need to be able to require "xulrunner 2.0 beta 11"
>  but that's impossible with the current guidelines...
>
>  Essentially, the number that gets incremented is _before_ the
>  pre-release, and unfortunately there's no time machine available to
>  determine how many increments will occur before the next tarball update,
>  so packages can't do
>      Require: xulrunner>  2.0-0.19.beta11.fc15
>      Require: xulrunner<  2.0-0.22.beta12.fc15
>
>  since we might just go straight to 2.0-0.20.beta12.fc15 or we might need
>  20 rebuilds of beta 11.  And depending on the specific NVR is suboptimal
>  too.
>
>  What I want to do for the XULRunner case specifically is change it to:
>      xulrunner-2.0-0.0.beta11_1.fc15 // first instance of beta 11
>      xulrunner-2.0-0.0.beta11_2.fc15 // rebuild of beta 11
>      xulrunner-2.0-0.0.beta11_3.fc15 // another rebuild
>      xulrunner-2.0-0.0.beta12_1.fc15 // first instance of beta 12
>      xulrunner-2.0-0.0.scm20110209_1.fc15 // scm snap from Feb 9 2011
>      xulrunner-2.0-0.1.beta13_1.fc15 // first instance of beta 13
>
>  So, the first 0 would signify a pre-release, the second 0 would be used
>  as sort of a "prerelease epoch" if needed as shown above, and it would
>  be followed by the pre-name, and then a release.  Normally, a hyphen
>  would precede the rpm release of a tarball, but we can't have that here
>  due to the fact that we're putting some of the version information in
>  the release, so I think underscore works just as well here, and is
>  better than a dot.
>
>  This would allow packages to do things like
>      Require: xulrunner>= 2.0-0.0.beta11
>      Require: xulrunner<= 2.0-0.0.beta12
>
>  Thoughts? 
Another possibility, since you're looking only for equality comparisons 
and not greater or less than comparisons, might be to keep the rpm 
versioning as-is and use a virtual provide for your own purposes, e.g.

Provides: xulrunner(version) = 2.0beta11

and in the dependent package(s):

Requires: xulrunner(version) = 2.0beta11

Paul.

[Christopher Aillon]

On 02/10/2011 01:36 AM, Paul Howarth wrote:

>  Another possibility, since you're looking only for equality
> comparisons
>  and not greater or less than comparisons, might be to keep the rpm
>  versioning as-is and use a virtual provide for your own purposes, e.g.
>
>  Provides: xulrunner(version) = 2.0beta11
>
>  and in the dependent package(s):
>
>  Requires: xulrunner(version) = 2.0beta11 
Except that some things will legitimately want to do comparisons, and 
that would lead to 2.0beta11 > 2.0 which is wrong.

[Rex Dieter]

On 02/10/2011 10:48 AM, Christopher Aillon wrote:
>  On 02/10/2011 01:36 AM, Paul Howarth wrote:
>
> > Another possibility, since you're looking only for equality comparisons
> > and not greater or less than comparisons, might be to keep the rpm
> > versioning as-is and use a virtual provide for your own purposes, e.g.
> >
> > Provides: xulrunner(version) = 2.0beta11
> >
> > and in the dependent package(s):
> >
> > Requires: xulrunner(version) = 2.0beta11
>
>  Except that some things will legitimately want to do comparisons, and
>  that would lead to 2.0beta11>  2.0 which is wrong. 
Fwiw, there isn't any > used here, just =

Otherwise, could try to leverage pkg-config here perhaps.  I've 
successfully used this approach before.

Use the output of:
pkg-config --modversion libxul
or
pkg-config --modversion libxul2
(or whatever)
for versioning (assuming this is granular enough for this purpose).

Otherwise, just invent something else artificial.

-- Rex

[Michael Schwendt]

On Wed, 09 Feb 2011 18:46:57 -0800, Christopher wrote:

> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Vers...
>  
>  So, this has been a problem for a while for me, but I'm just now getting 
>  to bring it up...
>  
>  Basically, packages need to be able to require "xulrunner 2.0 beta 11" 
>  but that's impossible with the current guidelines... 
The guidelines aren't perfect. They are based on common packaging pitfalls
related to versioning schemes that are incompatible with RPM. Such as:

  $ rpmdev-vercmp 0 2.0.beta11 1   0 2.0 1
  0:2.0.beta11-1 is newer

With the current pre-release scheme, you couldn't create a clean and
strict "equal to" dependency on "xulrunner 2.0 beta 11" anyway due to
the
%dist tag. With "beta11" moved into %release, you would always end up
with a ">" or ">=" dependency due to the build number.

>  Essentially, the number that gets incremented is _before_ the 
>  pre-release, and unfortunately there's no time machine available to 
>  determine how many increments will occur before the next tarball update, 
>  so packages can't do
>     Require: xulrunner > 2.0-0.19.beta11.fc15
>     Require: xulrunner < 2.0-0.22.beta12.fc15 
Same here. 

What exactly do you want to express with these two Requires?
A strict dependency on beta11? Knowing that beta12 _will_ be incompatible?
Then you should find a way to drop the 0.19 and .fc15 from the dependency,
since they are just disturbing the whole thing.

Would it be too far off to introduce your own 'xulrunner(abi)' dependency,
which would be independent from %version and %release?
Sort of

  Provides: xulrunner(abi) = 2.0-0.beta11

and

  Provides: xulrunner(abi) = 2.0-1

for the 2.0 final release.
You would still need to consider the same "release problems" related to
RPM version comparison:

  Requires: xulrunner(abi) = 2.0

(without the trailing -1!) would be satisfied also by the beta releases.
'>' and '>=' would make the dependency less strong, since e.g.
2.0-0.beta11 is > 2.0

[Michael Schwendt]

On Thu, 10 Feb 2011 11:04:42 +0100, I wrote:

>  '>' and '>=' would make the dependency less
> strong, since e.g.
>  2.0-0.beta11 is > 2.0 
Ignore this, please. It's truncated, I got distracted, it doesn't make
sense. Correct would be:

2.0-0.beta11 is _not_ > 2.0  as it's equal to 2.0 in a ">= 2.0"
dependency.

[Christopher Aillon]

On 02/10/2011 02:25 AM, Michael Schwendt wrote:
>  On Thu, 10 Feb 2011 11:04:42 +0100, I wrote:
>
> > '>' and'>=' would make the dependency less strong, since e.g.
> > 2.0-0.beta11 is>  2.0
>
>  Ignore this, please. It's truncated, I got distracted, it doesn't make
>  sense. Correct would be:
>
>  2.0-0.beta11 is _not_>  2.0  as it's equal to 2.0 in a ">= 2.0"
> dependency. 
Ah the versioning here is a little better...

And actually, we do have a virtual provides which was added when we 
switched from firefox to xulrunner as the gecko base, so people could 
just require gecko-libs/devel instead of needing to figure out whether 
they needed to require firefox or xulrunner, but it's always been set to 
%{version}-%{release}.  Of course that can, and probably should, change.

Thanks.

[Tom Callaway]

On 02/09/2011 09:46 PM, Christopher Aillon wrote:
>  Essentially, the number that gets incremented is _before_ the 
>  pre-release, and unfortunately there's no time machine available to 
>  determine how many increments will occur before the next tarball update, 
>  so packages can't do
>     Require: xulrunner > 2.0-0.19.beta11.fc15
>     Require: xulrunner < 2.0-0.22.beta12.fc15
>  
>  since we might just go straight to 2.0-0.20.beta12.fc15 or we might need 
>  20 rebuilds of beta 11.  And depending on the specific NVR is suboptimal 
>  too. 
Could you depend on a versioned directory that is more specific?

Alternately, a custom provides seems like a better solution, e.g:

Requires: xulrunner = 2.0
Requires: xulrunner(beta) > 11

I am not a fan of using underscores in the version-release, as that only
makes things more confusing for humans, even if it does provide a
workaround for this specific situation.

~tom

==
Fedora Project