GHC 9.12

[andreasabel]

[__2] trying: hackage-security-0.6.2.6 (user goal)
[__4] rejecting: lukko-0.1.2 (conflict: base==4.21.0.0/installed-d274, lukko => base>=4.12.0.0 && <4.21)

[phadej]

FWIW, I'll welcome if hackage-security (and cabal-install?) migrated to https://hackage.haskell.org/package/base-4.21.0.0/docs/GHC-IO-Handle-Lock.html

I think that implementation in base is ok since some time ago (base changelog doesn't mention much, https://gitlab.haskell.org/ghc/ghc/-/issues/17950 is the last related issue I can find, and lukko doesn't fix that at all atm #15).

If base implementation is still unacceptable, I'd like to learn why. And you should work towards making it good enough.

I'll update lukko now, but I might not do that in the future in timely manner.

[andreasabel]

Thanks for the bump.

For moving away from lukko, the question is who will do the code changes.
The authors of hackage-security have long moved on, and for code changes one needs actual code comprehension, whereas dependency bumping is just a routine job.

CC @Mikolaj

[phadej]

the question is who will do the code changes.

Maintainers of corresponding downstream packages. If they want & need timely new GHC support they should either migrate away, or tell why they cannot (or fork lukko which will require even more code comprehension).

one needs actual code comprehension

Are you implying that no-one understands what hackage-security does / how it works? That's worrying.

[andreasabel]

Are you implying that no-one understands what hackage-security does / how it works? That's worrying.

I personally only do formal maintenance for hackage-security. But I am only deputy maintainer.
@Mikolaj is the chief maintainer.

Looking through the commits it seems like hackage-security has been stable since the COVID era, larger changes start to be visible when going to the pre-COVID maintainer group: @phadej, @hvr, @23Skidoo.
I perceive the current maintenance work as never change a running system.

[phadej]

I'm sorry to repeat myself, but I gave you a heads up: If you want keep hackage-security timely updated with newer GHC releases, please migrate away from lukko. I cannot promise that it will be timely maintained unless it's clearly communicated why base locking is not good enough. But even then, I'd like to see base version made better in that case, to support wider needs. It's a shame if base has an implementation which is actually not good enough.

[Bodigrim]

For moving away from lukko, the question is who will do the code changes.

Isn't flipping the default value of lukko flag in hackage-security enough?

[phadej]

Isn't flipping the default value of lukko flag in hackage-security enough?

I don't know. Please have this discussion on hackage-security issue tracker.

[Mikolaj]

Thank you for the discussion and suggestions. I've opened haskell/cabal#10724 for further discussion.