Epochs... This is usually what you only resort to when no other options exist, and then you have to drag it around indefinitely as there's no way to get rid of them, only increasing epoch value...
With the annoyances and grief over this from "everybody", I introduce to you now finally a new feature in rpm: epoch deprecation! This will help you get rid of the epochs in a fairly easy fashion. So it works like this: * Epoch value is stored as a uint32_t (unsigned, where '-1' will due to it being unsigned become largest 32 bit unsigned integer: 4294967295) * By changing how epoch is treated to int32_t (signed), we get the possibility of having negative epoch values, such as ie. '-1' (and we don't really need .need suppport for epoch values as high as 4294967295. by changing the signedness to signed, the largest value for the signed integer will still be as high as 2147483647) * With the now negative value, it can now be used to deprecate epoch, where a negative epoch value of '-n' will beat 'n', ie.: -1:1-1 > 1:1-1 -1:1-1 < 2:1-1 -2:1-1 > -1:1-1 * So what about actually deprecating the epoch tag still present in the package (which it'll be, only that it'll be a negative one)? As the negative epoch will only be compared against other epochs, it will be ignored for where packages has none, ie.: 1-1 == -1:1-1 1-2 > -1:1-1 So what about backwards compatibility? Since rpm without suppport for epoch deprecation will consider packages built with an epoch of -1, it will consider it as 4294967295, which will help backwards compatibility in a sufficient manner since this epoch will always beat whatever epoch compared to, so there shouldn't be any incompatibilities caused by this wrt. packages built. Only incompatibility introduced by this will be building packages lackaing this support which won't acccept a negative epoch value. But considering deprecating epochs are unlikely of any importance (more likely cause of troubles in a release distro where other packages might depend on the packages specific epoch), I'd consider this as a non-issue. Etc., I hope my explanation about usage and behaviour sufficed, if not just ask, :) I also lack an account for the wiki, so if anyone would like to start document things like this on it, it would be greatly appreciated. Some things to keep in mind though; considering that some epochs has stayed around forever, when deprecating it, be sure to carry around the negative epoch for a while (ie. at least throughout the lifetime of releases for which you wanna deprecate epochs for packages of). This also should become less of an issue as the negative epoch will be ignored when comparing versions. Well I know a lot of people has requested the possibility of deprecating epochs for many years, so I'm happy to finally have brought an implementation of how to do this in a feasible manner for package maintainers. :) Another feature relating to same topic is the support for '~' in version tags for use with prerels, ie. like: foo-1.2~beta3-1 > foo-1.1-1 foo-1.2~beta3-1 < foo-1.2-1 This should avoid the need for dealing with prerelease versioning in the releae tag like whereas for the example above, in order to achieve the equivalence, you'd have something like this: foo-1.2-0.beta3.1 I'm not entirely sure whether ABF has been fixed to support '~' in filename, but it not, it will be fixed ASAP. Jeff, maybe you have some input on the '~' in version you'd like to comment on? :) -- Regards. Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
