2015-01-08 17:34 GMT+01:00 Jeffrey Johnson <[email protected]>: > > On Jan 8, 2015, at 5:59 AM, Per Øyvind Karlsen <[email protected]> > wrote: > > 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 > > > FYI: rpm-5.0 switched all integer data types to unsigned in 2008 to > simplify > interfaces and mitigate integer overflows. There is no reason that > I am aware of to revert (and many compatibility reasons NOT to do so, > not the least of which is consistency) and flip-flop back to signedness. > There's pretty much only two places epoch gets cast to a signed int, within rpmevr.c and in hdrfmt.c where it will be printed as a signed integer (%i rather than %llu). For the single case of the epoch tag, my concerns for integer overflows aren't really that great...
> > And I have proposed — as you should know — several ways to > phase out epoch (and distepoch) by changing macros configuration, > None of which I found satisfactory as they all involved hackery outside of rpm for whole distro during release upgrades, which comes at conflict with the dynamics of cooker... I'd rather leave it in the hands of maintainers to perform such actions themself, and considering rpm is responsible for adding an epoch, it should be responsible for deprecating it as well. > > * 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. > > > Say what?!? An Epoch: of 0xffffffff will be higher than any other > epoch. > Yes, for legacy apps, for which I find epoch being treated as 0xffffffff rather than -1 as satisfactory considering that if it were to consider it as -1 without support for this, it would behave exactly opposite of the desired behaviour, while treated as 0xffffffff it will always beat epochs, which is most likely exactly what you want.. If the rpm version is too old to contain support for, a package having an epoch that gets beaten by 0xffffffff are highly likely the behaviour desired considered that it's most likely older, especially in the contexxt of cooker. > And treating -1 specially forces every application > using RPM — including preexisting dead legacy code — to be modified > to handle the special case of -1. Many many many rpm applications do _NOT_ > call rpm lib functions to compare E:V-R[:D] correctly already. > Well, for all those applications who do use rpmlib and it's functions for EVR comparision, it will work without need for special modification. For those who doesn't, well.. same applies to '~', does it not? I've ported all packages in distro using rpm api to rpm5 api in the past without too much grief.. For any packages in the distro that would break in some way caused by this, I'd estimate their numbers being far smaller and more trivial to fix... > 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. :) > > > Many people have complained about many things in RPM , > not just epoch. Cherry pick “features” and claim whatever > you wish publicly as loudly as possible. > > 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? :) > > > Nope, got nothing whatsoever to say about twiddle-in-version. > > Go ask SuSE why they proposed twiddle-in-version at the RPM Summit > in September 2008. > > There are/were many other possible solutions than > Let’s make RPM behave Just Like dpkg. > Yet you did implement support for this in rpm yourself as well regardless of... -- Regards, Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
