> 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.
And I have proposed — as you should know — several ways to
phase out epoch (and distepoch) by changing macros configuration,
> * 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. 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.
> 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.
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
