Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cabal2arch creates bad PKGBUILD for cabal2arch #20

Closed
magthe opened this issue Jan 7, 2011 · 3 comments
Closed

cabal2arch creates bad PKGBUILD for cabal2arch #20

magthe opened this issue Jan 7, 2011 · 3 comments
Labels

Comments

@magthe
Copy link
Contributor

magthe commented Jan 7, 2011

cabal2arch (the binary) tries to load two files, ghc-provides.txt and library-providers.txt. These two files are installed by archlinux (the package). This means that the PKGBUILD for cabal2arch can't makedepend on archlinux but instead has to depend on it. In other words, since archlinux contain data files the basic assumption that executables only need to makedepend on all libraries is wrong for executables that use archlinux.

I think there are two solutions to this:

  1. Move the two data files to cabal2arch, that's where the function for loading them is so that's where they belong.
  2. Remove the data files from archlinux completely and make cabal2arch always load them from a URL. (Or at least make it load them from a URL by default, this might make more sense from a developer and testing perspective.)

I would prefer the second solution.

@magthe
Copy link
Contributor Author

magthe commented Jan 7, 2011

I should probably add that the two solutions are specific to cabal2arch. In the long run we need to address the more general problem of libraries having datafiles.

@peti
Copy link
Contributor

peti commented Jan 7, 2011

As a quick-fix, I've uploaded a new version of cabal2arch to AUR and kiwilight.com that declares a run-time dependency on haskell-archlinux. The PKGBUILD was hand-edited, though, so this is really a hack.

@magthe
Copy link
Contributor Author

magthe commented Feb 17, 2011

Remy, I think this can be closed, right?

@magthe magthe closed this as completed Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants