Take over filelock package

1

I intend to take over filelock: Portable interface to file locking (flock / LockFileEx).
It is a dependency of crucial Haskell infrastructure such as pantry and haskell-server (via acid-state).
I needs a fix to work with unix-2.8 as released with GHC 9.6:

I have been trying to communicate this on github to the maintainer Takano Akio since 2023-02-08.
I have tried to contact the maintainer by email 2023-03-12, but have gotten no response.

Preferably, the maintainer would come back, but I do not have much hope, their last public github activity was 2021-08-22.

8 Likes
2

(hackage-server, not haskell-server, presumably.)

2 Likes
3

Are you aware of GHC.IO.Handle.Lock ? This module is used within ghc-pkg for managing concurrent updates to package database.

I’m not sure if the filelock package provides any advantages over this interface though.

2 Likes
4

Note that if anyone wants to use this, you might consider using GHC.IO.Handle instead. Although both modules were intended to be internal to GHC, the latter is a de facto standard and may get stabilized accordingly. It exports everything from GHC.IO.Handle.Lock, anyway.

Source: Base stability - Google Sheets

Context: the proposed base/GHC split

3 Likes
5

Thanks for the pointers to GHC.IO.Handle.Lock!
For now, I am keeping the filelock package alive at GitHub - haskell-pkg-janitors/filelock: Portable interface to file locking.
Users might decide to drop filelock in favour of alternatives like the one you point out.

3 Likes
6

If I’m not mistaken such updates don’t need package takover and can go through the hackage trustees NMU process: hackage-trustees/policy.md at master · haskell-infra/hackage-trustees · GitHub

1 Like
7

Yes, they can, but the process is not really simpler. If the maintainer is unlikely to come back, NMU’s don’t solve the problem long-term.
In this case, should the maintainer come back, I am happy to hand back maintainership.