On Sat, Oct 07, 2017 at 12:45:14PM -0400, Neal Gompa wrote:
> On Sat, Oct 7, 2017 at 12:31 PM, 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.
> >
>
> No. Please don't do this. If anything, I want Epoch to be a thing that
> we reset on new distribution releases, since our tooling does support
> this and the distribution upgrade procedures have long since been
> adapted to handle it. Epochs shouldn't be permanent. :(
>
> > 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.
> >
>
> We could do this now with the Release field. I've mentioned it
> numerous times in the past that this is a well-proven idea. SUSE does
> this now with OBS, which is why their release field is set to the
> following format:
>
> Release: <COMMIT_INC_NUM>.<BUILD_INC_NUM>
>
> The values above are automatically written by OBS, ignoring whatever
> Release is set to. When the version is bumped, <COMMIT_INC_NUM> is
> reset to 1. Whenever a rebuild occurs for whatever reason, the
> <BUILD_INC_NUM> is bumped, but it resets to 1 on a new commit+submit
> build.
>
> So, for example:
>
> 1. foo v1 => Release: 1.1
> 2. adjust spec => Release: 2.1
> 3. auto-rebuild due to dependency change => Release: 2.2
> 4. adjust spec => Release: 3.1
> 5. foo v2 => Release: 1.1
>
> Since we don't have nice things like auto-rebuild of reverse
> dependencies for packages, we could probably simplify the scheme to
> be:
>
> Release: <COMMIT_INC_NUM>%{?dist}
But the version is evaluated before the release no? So how would rollback work
if we're only touching the release field (ie the last one evaluated)?
Pierre
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
