-----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.
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.
>
> 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.
>
>
> --
> Matthew Miller
> <mattdm@xxxxxxxxxxxxxxxxx>
> Fedora Project Leader
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlnZBTkACgkQaVcUvRu8
X0y4UQ/9GBqUQZrcj92eA4icLk6N64STpZRRm6HZM4mFrZwh4lop0h9pXUKQ7rjG
CryZnaMgtN3VPQkzpPkgwfQq510etlda9qIIFihS/HQI2Uxyx5ZOhhEIKHd2VH48
3N2TOOht1InePM7AOFxk3nM26TBSzFjSka33gfkS0/GarSe3E97+LmXc3qEfN5FY
zpHAbH9TW8nTqqXxYAH15MtHJr8Hv/KGxyGSbIyFXrSM+UmFNhDT2xNcC7L/JgzK
Vp6L+G42Ss4GKbgU1/rV5JQhhdxm8tHaaGnnjauz3URtNqmJ3VAHKnmn8HDht7IY
gIGt/6yCev7HdumVifyiyovuiaXh50JV2G9syApBokjHvXFFZpnY0WybMHeuEK0o
I5sVkT0shvsqs4lZIbFw9NertHBR2DopYeJy7GNxfObhbgbZsiJvNwoHLQHEWvpv
yrBAx+Nuply51+fgSs41FsNjrCDLsz7pkLZqPBeDfd11AfxkKe4H9fQecOU1vNqm
axRjCfRNEwyLdVXwEU3O/Z0os/QY7yKKqQCJA+mMDyzEjiY9rm+yGFYjGixWbp+w
nN5+ZRvFqxTiCBYHm5yhLezKLo3yUcgJ+6IrJgNzVpq4Amx2luzh+b/NVV/jn3Lm
SLNJ5lvwdEIUC+dh6fAInnWiHlpPLCTWh5miPBsE91LJi+pLUTQ=
=GzSG
-----END PGP SIGNATURE-----
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
