On Jan 8, 2015, at 8:44 PM, Per Øyvind Karlsen wrote: > > 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).
Two places you have found != all places that need changing. > 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. > Then make a proposal and discuss on [email protected] if you want to make the change. Otherwise hack away as you wish. > > >> * 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... > Your estimates were measured ... how? > > > >> 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... > You are welcome. Whether I implemented has nothing to do with whether the feature is useful or necessary. You continue to choose rpm features to implement that are disruptive and not all that useful. E.g. how many distros have adopted libcpuinfo or Distepoch? Have you proposed your changes to any other distros interested in using rpm? What comments were received? Keep up the good work! 73 de Jeff > -- > Regards, > Per Øyvind > _______________________________________________ > OM-Cooker mailing list > [email protected] > http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
