Repository navigation
Revise flag from automatic to manual is irreversible #1420
Description
On Hackage, when revising a package metadata, revising a flag from automatic to manual is permitted, but the reverse is not. Hence, after a mistaken revision from automatic to manual, the package metadata gets stuck with the wrong setting.
Example: hs-onnxruntime-capi-0.1.0.0 is stuck with pkg-config as a manual flag, while it was an automatic flag before. (It should be manual with a default set to false, but that's now an unreachable configuration.)
Activity
phadej commentedon Jul 30, 2025
Going into one direction have been intentional 9fcef72, but I'd argue that revisions should always be reversible. So if
manual -> automaticis considered bad for some reason thanautomatic -> manualmust be forbidden as well.Sadly the commit message doesn't motivate change further. Why allowing only one direction and not other? Safe option would be to disallow both, yet I don't see a problem with allowing both if one is considered important.
IMO the reversibility of revisions (i.e. always being able to undo revisions) is the most important feature of revision system. (Otherwise Hackage Trustees cannot be trusted, they are humans and can make mistakes, which they can not undo!).
gbaz commentedon Jul 30, 2025
The one direction of that is also documented here: https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md
Note that this is not the only "one way" revision -- it is also allowed to add from a very special subset of dependencies, but not to remove any dependencies at all.
I don't recall the exact logic behind this choice, but there's some related reasoning both in the linked commit and in the documentation I linked. Its something like going to manual makes things more configurable for users and is in that sense "safe", but going to automatic may make a previously working configuration unusable. Its certainly debatable whether an outright ban is the best choice -- arguably what we should do is change revisions so that not trustees but admins can override such decisions. Or maybe we should just allow one to "revert" a revision?
Note also that the heavy restrictions on revisions were largely driven by a response to user anxieties about revisions -- they didn't like the idea of things changing, and so the more we restricted the surface and vetted it, the better we could assuage that.
By the way @wenkokke you wrote "It should be manual with a default set to false, but that's now an unreachable configuration" -- did you mean it should be automatic with default false? One can always change the defaults of a manual flag, I believe.
phadej commentedon Jul 30, 2025
It's not "safe". Turn any automatic flag in https://hackage.haskell.org/package/transformers-compat-0.7.2 to be manual, and you will break some configurations. (Downstream would be required to flip flags manually).
Arguably it's a missing feature in
.cabal. If.cabalhad haskell/cabal#11053, then we could addfake-dependsbaseandbase-orphans, and IMHO those fake dependencies could be added and removed safely by revisions. Then you won't need to be able to add truebaseandbase-orphansdependencies. Those are "hacks".phadej commentedon Jul 30, 2025
I suggest that we ban flag manual <-> automatic change.
I'd argue that both directions may make working configurations unusable.
But so can build-depend revisions. So to me that is lacking argument. The property than you can undo revision to me is far more important. If you accidentally made revision which made something unusable, you should be able to undo it. OP wasn't warned that
automatic -> manualchange is irreversible.gbaz commentedon Jul 30, 2025
The "safe" argument is that if you have an automatic flag that is made manual, then one can locally always just force the flag to how the automatic could have resolved. I.e. you may need to change your build, but you can do so. However, if a manual flag becomes automatic, then it may always "automatically" pick the option you don't want, and you can't override that. I.e. as you write in one case "downstream would be required to flip some flags manually." Yes. However, in the other case, downstream would be unable to find any flags to flip, much worse.
If I recall, there were specific use cases where automatic -> manual was necessary, which is why it was allowed, but I don't know which ones offhand, this was all some time ago. It might be fine to just disallow again for now, then revisit if/when the need arises.
phadej commentedon Jul 30, 2025
You can force automatic flag to the particular value too. I.e. you can override automatic selection. That what
cabal.project.freezefiles do:constraint: package +automatic-flag. The same way as with manual ones.gbaz commentedon Jul 30, 2025
Ah, the semantics are just
automaticwill automatically try the negated flag if the default doesn't work (i.e. backtrack), while manual won't, but otherwise they're the same?In that case, I can't see a good argument for allowing one but not the other, and I'm not sure how to reconstruct the logic that got us here. PR welcome to make it uniformly editable both ways.
phadej commentedon Jul 30, 2025
At its simplest yes.
wenkokke commentedon Jul 31, 2025
It should be manual with default false. I cannot change the default of the flag now that it is manual.
wenkokke commentedon Jul 31, 2025
Changing the whole infrastructure to allow a particular use case seems... untenable? Wouldn't it be better to just make admins all powerful, breakage be damned, though with heavy warnings?
phadej commentedon Jul 31, 2025
I might be wrong, but the reason is probably because flags are
manual: Falseby default, and that caused (causes?) issues, because e.g.cabal checkdoesn't warn that neithermanualnordefaultsettings for flags are explicitly set.EDIT: There is soon a decade old issue about that haskell/cabal#1890 (comment)
gbaz commentedon Jul 31, 2025
Ah, that's frustrating. That doesn't correspond to the documentation, which says that flag defaults should be editable. So I'll say now that three PRs would be welcome (or one PR doing three things).
First: making flag defaults editable. Second, making both sides of manual <-> auto editable. Third, giving admins but not trustees broader permissions to make much more sweeping cabal file revisions than our rules allow. The latter is the trickiest, and probably the least important, since its been very rare that any requests to extend allowed revisions have happened.