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}
Though I would love to see us be able to do auto-rebuild of reverse
deps on submit and auto-bundling with an update, as that would
alleviate a huge burden, I don't think that will ever happen. :(
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
