[arch-haskell] Re: Replacing the current comment with a Maintainer field
simons at cryp.to
Sat Oct 12 07:37:24 UTC 2013
> I accidentally pushed that change to the provides list with another
> commit, but I wanted to ask the mailing-list about it before pushing
> it (it caused PKGBUILD to no longer have redundant haskell-cabal and
> other dependencies).
yes, there are both advantages and disadvantages to this change. Now
that PKGBUILDs don't list the dependencies provided by GHC anymore, we
no longer rely on 'provides', and any ArchLinux package manager ought to
be able to handle our builds just fine. This is good, of course. On the
other hand, our PKGBUILDs are now implicitly designed to be used by GHC.
If there were a new production-ready Haskell compiler to emerge that
would provide a different set of standard libraries, then those PKGBUILD
files would no longer work correctly because of those implicit
I feel that's a theoretical problem, though, and we can worry about that
later when a new major compiler actually appears, which is probably not
going to happen any time soon.
> I saw that you added options to personalize names of generated
> packages: do you plan to support packaging multiple versions of a
> single library?
Yes, my PKGLIST now contains both package names from ArchLinux and
Cabal: <http://github.com/peti/arch-haskell/blob/master/PKGLIST>. This
allows us to include multiple versions of the same package in the
distribution, i.e. like this:
# ArchLinx pkgname Cabal pkgname Version Release
haskell-pandoc1 pandoc 1.6 1
haskell-pandoc pandoc 2.0 1
I'm also planning to augment PKGLIST with a set of options that are to
be applied in the conversion, for example:
# ArchLinx pkgname Cabal pkgname Version Release Flags
haskell-pandoc pandoc 1.6 1
haskell-pandoc-full pandoc 1.6 1 -fhighlighting -fciteproc
I'm not quite there yet, and this change is going to require further
genereralization of the archhaskell library API, but IMHO that feature
would be worthwile to have.
More information about the arch-haskell