On Wed, 09 Feb 2011 18:46:57 -0800, Christopher wrote: > http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Version_in_Release > > 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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
