On Sat, Oct 7, 2017 at 12:47 PM, Igor Gnatenko
<ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sat, 2017-10-07 at 12:31 -0400, Matthew Miller 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)".
> Please, don't.
>
> Epoch is horrible hack and breaks Requires / any other dependencies in
> unpredictable ways.
>
> Imagine, you have systemd which would have Epoch: 1 and Version: 234..
> Now you do Requires: systemd >= 235 and the dependency is satisfied
> because 1:234 > 235.
>>
>> 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.
> openSUSE uses distepoch, so any version of next release of distribution
> "upgrades" old ones (even if version is lower). So far we use yet
> another hack called %{?dist} in Release and assuming that packagers
> will make sure that their builds for new distro are higher.
>
That's OpenMandriva that uses it, but libsolv does support handling it
for upgrade calculations. We'd need to complete support for DistTag
and implement support for DistEpoch in rpm, but it's a much cleaner
way to handle that if you care for the "always go up on upgrade"
thing.
I experimented a bit with it and it seems nicer than what we do now,
and it cleans up the Release tag, which is always nice. :D
> I am strongly against using Epoch for purpose like this, but we could
> reuse distepoch. But probably just making assumption like
> update==distro-sync would do this trick as well.
Yep. distro-sync also now has the alias of dist-upgrade, which makes
it clear what purpose it's for.
>>
>> 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.
> I don't see how this could work at all.
Well, we're bad at automating stuff like this in Fedora, so I doubt we
could pull that off. :(
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
