Skip to content

listx/cabal2pkgbuild

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

27 Commits
 
 
 
 
 
 

Repository files navigation

NOTICE

This project is no longer maintained. Please have a look at using the Nix package manager which handles things in a much better way here.

cabal2pkgbuild

cabal2pkgbuild is a script used to generate proper PKGBUILD files from any .cabal file from Hackage, with the help of cblrepo (which is currently used to maintain Haskell packages on Arch Linux).

Installation

This script is available on the AUR.

Dependencies

These are the following dependencies on Arch Linux:

  • cblrepo
  • coreutils
  • grep
  • pacman
  • sed
  • zsh

Usage

Create an empty folder, e.g., my-haskell-packages.

Patch Folder

You must have an empty folder named patch within this folder (i.e., my-haskell-packages/patch. This folder will be accessed by cblrepo to generate the proper PKGBUILD; you can have 3 kinds of patches:

  • <hackage_package_name>.cabal
  • <hackage_package_name>.pkgbuild
  • <hackage_package_name>.source

Essentially, the idea is to patch any misbehaving Hackage packages so that a proper, working Arch Linux package can be generated. Refer to the cblrepo documentation for further explanation.

Database Generation, PKGBUILD Creation, and Package Installation

Go into my-haskell-packages, and create a file listing all Hackage packages, one on each line, that you'd like to create PKGBUIKLDs for. Optionally you can specify an explicit version through comma (','). So format of each line is <package-name>[,<package-version>]. This is called the <hackage_packages_file> file by convention.

The following is a sample <hackage_pacakges_file> file:

bindings-DSL
bindings-GLFW
GLFW-b
transformers-compat
contravariant
distributive,0.4.3.2
comonad
semigroupoids
bifunctors
generic-deriving
profunctors
reflection
distributive
MonadCatchIO-transformers
lens
linear
rosezipper
elerea
mersenne-random
vect
netwire

The names of the packages are taken directly from the Hackage site (i.e., the case-sensitivity matches the original names on Hackage). As the packages here are added in order, you should put them so that the dependencies are built first. The lens package, for example, has a ton of dependencies and all of these are listed before lens itself. It takes some trial and error to get this right (the makepkg mode will output failures as pacman fails to find the necessary dependencies), but it should not be too difficult.

We now run the script 3 times:

/path/to/cabal2pkgbuild.sh <hackage_packages_file> initdb-sync
/path/to/cabal2pkgbuild.sh <hackage_packages_file> pkgbuild
/path/to/cabal2pkgbuild.sh <hackage_packages_file> makepkg

The initdb-sync mode initializes the cblrepo database, populating it with all of the system Haskell packages already installed on your computer.1 More importantly, it lets cblrepo know which version numbers are the latest ones posted on Hackage. It then adds the listed packages in <hackage_packages_file>. It does this by creating a cache folder first; if the corresponding cabal files from <hackage_packages_file> already exist, they are not downloaded. The user is responsible for keeping track of the state of cache, although as cabal files are saved with the version number in the file name, there is no danger of somehow overwriting wrong versions through this script.

If you want to skip the sync with Hackage (e.g., on subsequent immediate runs of this script), use initdb instead of initdb-sync.

The pkgbuild mode removes all haskell-* folders in the current folder, before populating the current directory with all the Hackage packages' generated PKGBUILD folders.

Finally, the makepkg mode goes through each package and runs makepkg -sif for that package. This mode is a convenience mode: you can manually go into each generated PKGBUILD directory and do the usual makepkg -sf/pacman -U combo yourself --- however, it is probably easier with this mode because you retain the dependency ordering information (the order of the packages in <hackage_packages_file>). That is, if you manually built the packages yourself, you'd have to remember which packages to build first.

Footnotes

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages