<br><br><div class="gmail_quote">On Wed, Mar 30, 2011 at 6:24 AM, Peter Simons <span dir="ltr"><<a href="mailto:simons@cryp.to">simons@cryp.to</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The following message is a courtesy copy of an article<br>
that has been posted to gmane.comp.lang.haskell.arch-linux as well.<br>
<br>
Hi Mathew,<br>
<br>
thank you for sharing your thoughts and insights.<br>
<div class="im"><br>
> I guess I am creating this thread due to the frustrations of using<br>
> cabal2arch/AUR for haskell packages (instead of using the standard<br>
> cabal install).<br>
<br>
</div>Your frustration is quite understandable. A number of PKGBUILD files<br>
published on AUR don't actually work. Others do work, but they're<br>
significantly out-of-date, which effectively prevents other packages<br>
from being installed. Haskell support on ArchLinux is far from perfect.<br>
<div class="im"><br>
<br>
> I previously had issues, mainly with having to manually update AUR<br>
> installed cabal packages due to them not updating (which was recently<br>
> fixed by forcing the update through ghc)<br>
<br>
</div>We have recently picked up the habit of bumping the $pkgrel field of<br>
every package that needs to be re-built because of an update of one of<br>
its dependencies, so this particular problem should be a thing of the<br>
past. The repository <<a href="http://github.com/archhaskell/habs/" target="_blank">http://github.com/archhaskell/habs/</a>> contains a<br>
set of packages that can be expected to be compile fine. Those packages<br>
are also fairly up-to-date, and we publish those files on AUR, too.<br>
<br>
Haskell packages outside of HABS, however, aren't maintained much, and<br>
they're probably not reliable. Is there any specific package currently<br>
not included in HABS that you would like to see supported?<br></blockquote><div><br></div><div>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)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
> [The] main issue seems to be that the granularity of cabal package<br>
> system is a lot finer then Arch's.<br>
<br>
Yes, exactly. In Cabal, a package can be installed in any number of<br>
different versions, and these just co-exist. Pacman, however, wasn't<br>
designed to do this. It does distinguish $pkgname and $pkgver, but only<br>
one version of $pkgname can be installed at a time. When we maintain<br>
packages in ArchLinux, we perform two tasks:<br>
<br>
1) We convert Cabal to PKGBUILD, and we<br>
<br>
2) figure out a conflict-free set of versions that can be installed<br>
at the same time.<br>
<br>
Unfortunately, part (2) is way more difficult than (1). :-)<br>
<div class="im"><br>
<br>
> Wouldn't it just be smarter to have the archlinux haskell environment<br>
> set up like this.<br>
><br>
</div><div class="im"> > - ghc is an official package in the official repository<br>
><br>
</div> > - haskell-platform will be the same as it is currently [...].<br>
<div class="im"> ><br>
> - All other libraries users would just install/update with cabal<br>
> install and not through AUR/cabal2arch/bauerbill etc etc.<br>
<br>
</div>Yes, I agree, and I think what we're actually doing is pretty close to<br>
your description. The complete Haskell Platform is part of [extra], and<br>
everything else can be installed through Cabal. Popular applications<br>
written in Haskell, like darcs, are also available from [extra], and<br>
these packages usually don't depend on GHC or any other Haskell package.<br>
On top of this, there is a community-driven binary repository accessible<br>
by adding the lines<br>
<br>
[haskell]<br>
Server = <a href="http://andromeda.kiwilight.com/$repo/$arch" target="_blank">http://andromeda.kiwilight.com/$repo/$arch</a><br>
<br>
to /etc/pacman.conf, which adds another ~200 popular Haskell packages.<br>
<br>
<br>
> - Haskell packages that provide binaries [should build their<br>
> dependencies on-the-fly via Cabal]. This allows building of packages<br>
> that use outdated packages (such as leksah ...)<br>
<br>
That is a great idea. As far as I know, no-one has ever tried doing that<br>
before. It would be interesting to know whether this approach works well<br>
in practice. One source of trouble could be that all dependencies have<br>
to be $makedepends, but some libraries cannot be $makedepends, because<br>
they need auxiliary data files installed at run-time. Problems such as<br>
this can be worked-around, no doubt, but it's likely to be some effort.<br></blockquote><div>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 ;)</div>
<div><br></div><div>Also is there any reason the libraries have to be $makedepends instead of just having the dependencies tracked by cabal via the PKGBUILD?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Another drawback is that this scheme may perform redundant compilations,<br>
because intermediate packages aren't re-used in any way.<br>
<br></blockquote><div>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)</div>
<div><br></div><div>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</div>
<div><br></div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> [My] experience of using cabal2arch/AUR hackagedb packages have just<br>
<div class="im"> > been a massive pain for years (I was basically forced to do manual<br>
> package dependency management), and as my haskell colleges/friends<br>
> have (rightly) stated, just use cabal.<br>
<br>
</div>Yes, indeed, that is good advice. The installation can be managed with<br>
cabal-install just fine. For some users, Cabal is probably the superior<br>
choice, especially for those who have a deep understanding of the<br>
problems involved in dependency resolution, package management, etc.<br>
<br>
For other users, Cabal is not an option because their needs are<br>
different. For instance, large-scale binary package distribution cannot<br>
be done with Cabal, but Pacman can do it just fine. ;-)<br></blockquote><div>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</div>
<div><br></div><div>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</div>
<div><br></div><div>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</div>
<div><br></div><div>Im just thinking about future scenarios here</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Take care,<br>
<font color="#888888">Peter<br>
</font></blockquote></div><br>