Decomission v1-register --gen-script and v1-unregister --gen-script

[Bodigrim]

The v1 commands v1-register and v1-unregister are obsolete by now, but even in their prime time - as witnessed by comments - their usage with --gen-script was not well attested or understood. Pruning this mode leads to surprising reduction of rather hairy code.

By default v1-register just goes ahead and registers a package. It also has a mode --gen-pkg-config to generate a .conf file, which a user can manually register by running ghc-pkg register.

Now --gen-script mode used to generate a shell script, which would run ghc-pkg register on the same .conf file (embedded). Why would anyone really want that? I have no idea and the comment quietly recognises that "In practice this aspect was not especially popular" and "The script generation [is] not well used or tested".

The v2 commands never use --gen-script feature.

The documentation (unchanged since 1658ad8 in 2005) used to claim that package distributors should be using register --gen-script and unregister --gen-script to generate register.sh and unregister.sh to be included in their packages. This does not seem to reflect the reality.

E. g., https://packages.debian.org/trixie/amd64/libghc-tasty-dev/filelist does not contain any shell scripts, only tasty-*.conf file. Same on Fedora: https://packages.fedoraproject.org/pkgs/ghc-tasty/ghc-tasty-devel/fedora-rawhide.html#files

Indeed inspecting build logs such as https://kojipkgs.fedoraproject.org//packages/ghc-tasty/1.5.3/28.fc44/data/logs/x86_64/build.log confirms that package distributors use v1-register --gen-pkg-config and don't use --gen-script.

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[ulysses4ever]

Thank you for the well-articulated argument. Someone will certainly come complaining but I'm of the opinion that we should have long started ripping out the v1 machinery. Also someone will argue for a deprecation procedure. But I don't see a point to do that for such esoteric parts of the interface.

[Bodigrim]

Can I have more reviews please? ;)

[philderbeast]

It would be good to move the motivation to a separate issue so discussion could happen there.

In reviewing this, I tried to exercise the --gen-script and --gen-pkg-config to see concretely what we'd be removing. I wasn't successful within the time I gave to it. This is an area of Cabal I'm not too familiar with. I also tried spying on cabal-testsuite/PackageTests/InternalLibraries/setup-gen-script.test.hs with --keep-tmp-files without much success either.

I don't feel I'm familiar enough with this feature to approve its removal.

There may still be some use of --gen-script in the wild, searching GitHub for "gen-script" with Haskell, in particular with cblrepo:

The goal of cblrepo is to aid in maintaining a consistent set of Haskell packages, e.g. for a Linux distribution. Currently it's heavily influenced by the work required to maintain Haskell packages for Arch Linux, but it's proven useful also for other distributions.

[Mikolaj]

Also, how do we plan to decomission it? A longer deprecation period to let people get in contact with us if they still need it?

[ulysses4ever]

i think @jappeace mentioned a brilliant idea in one of the previous calls: if we know that the feature is broken, there's no reason to use the deprecation procedure. The reasoning is that the deprecation procedure is supposed to help the users of the features, but a broken feature has none.