On Sat, Oct 7, 2017 at 1:10 PM, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
> 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)?
>
I was addressing the increment on every build thing with my
suggestion, not the rollback bit. Rollback would require a temporary
(i.e. for the distro release that it applies to ONLY) Epoch to bump it
back down. Epochs should go away after they're no longer necessary.
Though, technically, as Florian mentioned, distro-sync also works
without having to do Epochs.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
