On 7 October 2017 at 12:31, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
> On Sat, Oct 07, 2017 at 10:33:38AM -0400, Colin Walters wrote:
>> I'm personally very in favor of this; of course my usual refrain
>> here is that we should *try* new things and have the ability
>> to back them out if they don't work (the latter bit is what the
>> current system doesn't support).
>
> You know, we could easily _start_ supporting the thing you want if we
> switched from "Epoch is a horrible confusing hack that should never get
> used" to "We increment Epoch every time instead of Release (and don't
> reset back to 1 on new versions)".
>
> We could even define Release to %{epoch} and remove it from spec files,
> giving a user-visible indicator, even if that's not what the tools sort
> on. Or, I guess, we could to the other way around and define Epoch to
> equal release.
>
> We could also change the tools to increment with every build rather
> than manually — then, things like git-revert-and-build- would work. The
> ability to revert to previously-existing binaries *without* rebuilding
> would take more invasive tooling changes, of course.
>
>
If there is one thing I have learned in 20 years of dealing with
RPMS... DON'T PLAY AROUND WITH EPOCH. It is a hack which should only
be used as a last resort and a lot of tools are built around that
assumption.. even if they don't know it. Every time we have done
things with Epoch we have regretted it because of this.
At a certain point, if you want/need to do these things, it is better
to burn it from the ground and come up with a new packaging system
(and relearn all the second system problems involved with that).
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
