Dne 7.10.2017 v 18:45 Neal Gompa napsal(a):
> 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
This does not necessarily work in case when subpackages are using
different versions from main package. But if we always increased
release, it would not hurt ... OTOH, it would not solve the typical
issues with 1.0.0.rc1 updated to 1.0.0 ....
Vít
>
> 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. :(
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
