[arch-haskell] Issues with cabal2arch/AUR packages

[Mathew de Detrich]

On Wed, Mar 30, 2011 at 6:24 AM, Peter Simons <simons at cryp.to> wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.lang.haskell.arch-linux as well.
>
> Hi Mathew,
>
> thank you for sharing your thoughts and insights.
>
>  > I guess I am creating this thread due to the frustrations of using
>  > cabal2arch/AUR for haskell packages (instead of using the standard
>  > cabal install).
>
> Your frustration is quite understandable. A number of PKGBUILD files
> published on AUR don't actually work. Others do work, but they're
> significantly out-of-date, which effectively prevents other packages
> from being installed. Haskell support on ArchLinux is far from perfect.
>
>
>  > I previously had issues, mainly with having to manually update AUR
>  > installed cabal packages due to them not updating (which was recently
>  > fixed by forcing the update through ghc)
>
> We have recently picked up the habit of bumping the $pkgrel field of
> every package that needs to be re-built because of an update of one of
> its dependencies, so this particular problem should be a thing of the
> past. The repository <http://github.com/archhaskell/habs/> contains a
> set of packages that can be expected to be compile fine. Those packages
> are also fairly up-to-date, and we publish those files on AUR, too.
>
> Haskell packages outside of HABS, however, aren't maintained much, and
> they're probably not reliable. Is there any specific package currently
> not included in HABS that you would like to see supported?
>

My main issue was basically with packages such as yesod, which rely on a lot
of other packages (and by a lot, I mean a lot, I think a fresh install does
around 30 package installations) and because yesod has so many packages you
have some that are updated and others that are out of date (which describes
the problem I was describing earlier)


>
>
>  > [The] main issue seems to be that the granularity of cabal package
>  > system is a lot finer then Arch's.
>
> Yes, exactly. In Cabal, a package can be installed in any number of
> different versions, and these just co-exist. Pacman, however, wasn't
> designed to do this. It does distinguish $pkgname and $pkgver, but only
> one version of $pkgname can be installed at a time. When we maintain
> packages in ArchLinux, we perform two tasks:
>
>  1) We convert Cabal to PKGBUILD, and we
>
>  2) figure out a conflict-free set of versions that can be installed
>    at the same time.
>
> Unfortunately, part (2) is way more difficult than (1). :-)
>
>
>  > Wouldn't it just be smarter to have the archlinux haskell environment
>  > set up like this.
>  >
>  > - ghc is an official package in the official repository
>  >
>  > - haskell-platform will be the same as it is currently [...].
>  >
>  > - All other libraries users would just install/update with cabal
>  >   install and not through AUR/cabal2arch/bauerbill etc etc.
>
> Yes, I agree, and I think what we're actually doing is pretty close to
> your description. The complete Haskell Platform is part of [extra], and
> everything else can be installed through Cabal. Popular applications
> written in Haskell, like darcs, are also available from [extra], and
> these packages usually don't depend on GHC or any other Haskell package.
> On top of this, there is a community-driven binary repository accessible
> by adding the lines
>
>  [haskell]
>  Server = http://andromeda.kiwilight.com/$repo/$arch
>
> to /etc/pacman.conf, which adds another ~200 popular Haskell packages.
>
>
>  > - Haskell packages that provide binaries [should build their
>  >   dependencies on-the-fly via Cabal]. This allows building of packages
>  >   that use outdated packages (such as leksah ...)
>
> That is a great idea. As far as I know, no-one has ever tried doing that
> before. It would be interesting to know whether this approach works well
> in practice. One source of trouble could be that all dependencies have
> to be $makedepends, but some libraries cannot be $makedepends, because
> they need auxiliary data files installed at run-time. Problems such as
> this can be worked-around, no doubt, but it's likely to be some effort.
>
I will likely make an attempt in a couple of weeks when I have holidays (it
would be a tool like cabal2arch that would convert haskell packages that
create binaries into PKGBUILDS). There were other issues with the past, but
I think you get the general idea of whats happening ;)

Also is there any reason the libraries have to be $makedepends instead of
just having the dependencies tracked by cabal via the PKGBUILD?


>
> Another drawback is that this scheme may perform redundant compilations,
> because intermediate packages aren't re-used in any way.
>
> Yes, I already had some sought of an idea as a solution. If PKGBUILD finds
a dependency that it can install through cabal without conflicts, then it
would do a proper cabal installation of that package (so future
installations would just use that install). This however would cause issues
regarding fakeroot, by default cabal install packages in the users home
directory and if we do this we don't want another cabal installation of
libraries in root (we could alternately make cabal install libraries by
default in /usr/lib or something like that, but this creates many other
issues)

The other problem with this method is that it probably breaks a 'rule' in
package management, that is, its making changes to your system outside of
installing the actual package (which are only required to build the
package), which in terms of general package management, and are not tracked
by arch's package manager

The real beauty of this method though, is there is nothing stopping from
PKGBUILD detecting library installs from AUR, as well as library installs
from cabal install


>
>  > [My] experience of using cabal2arch/AUR hackagedb packages have just
>  > been a massive pain for years (I was basically forced to do manual
>  > package dependency management), and as my haskell colleges/friends
>  > have (rightly) stated, just use cabal.
>
> Yes, indeed, that is good advice. The installation can be managed with
> cabal-install just fine. For some users, Cabal is probably the superior
> choice, especially for those who have a deep understanding of the
> problems involved in dependency resolution, package management, etc.
>
> For other users, Cabal is not an option because their needs are
> different. For instance, large-scale binary package distribution cannot
> be done with Cabal, but Pacman can do it just fine. ;-)
>
I think we also need to take into account that haskell's programming
'environment' is different from other languages. With GHC, its a statically
compiled language which means that libraries are compiled into object files.
Unlike C/C++ however, GHC's runtime basically changes every time a new
haskell-platform is released, where as with C/C++ relies on glibc,  which
changes once every few years. Old C/C++ libraries will generally with with
gcc for years without needing recompilation

Also haskell programs/libraries tend to follow the unix philosophy, (do one
thing and do it well), which means that haskell packages tend to have a
massive number of small dependencies instead of a few large ones (that you
typically find in C/C++, boost as an example). This isn't a bad thing about
Haskell (in fact its a great redeeming feature), it just means we have to
deal with a language that does heavy static compilation/recompilation and
typically has very large dependency trees on packages. Dealing
with dependency issues is a lot less trivial if you have a trivial amount
of dependencies in the first place

If myself (or someone else) ends up making a tool that for converting
haskelldb packages that provide binaries into AUR PKGBUILDS that uses cabal
for dependency tracking, we could get into a situation where it creates a
conflicting impression on new archlinux users onto how exactly to set up
their haskell environment in arch. Would there be any issue in making an
'official' arch-haskell tool similar to baeurbill that would just
automatically create PKGBUILDS out of cabal2arch for the users that wish to
install haskell libraries through AUR and that all current AUR packages that
are not part of the haskell-platform would be removed (and actually moved
into the official repository)?. Then haskell packages that provide binaries
(aka programs) would be able to track dependencies regardless if they are
installed via the current method (of cabal2arch PKGBUILDS) or by cabal
install

Im just thinking about future scenarios here


> Take care,
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20110330/7197ad62/attachment.htm>