[Haskell-cafe] Re: cabal and platform-independent haskell
installation management (again) (Re: Re: Ubuntu and ghc)
barsoap at web.de
Wed Jun 4 11:22:52 EDT 2008
Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> On Wed, 2008-06-04 at 15:14 +0100, Claus Reinke wrote:
> > > I think that's fundamentally the wrong approach. We shouldn't
> > > have to build a "Haskell installation manager". Would you also
> > > want installation managers for Perl, Python, Ruby, C, C++, etc.
> > > each with their own different user interfaces and feature sets?
> > > I think not - you want a single package manager for the whole
> > > system from which you can install/uninstall libraries for any
> > > language.
> > >
> > > This is something that Windows gets completely wrong. Why do I
> > > have twelve icons in my status bar all representing little
> > > programs that are running in the background checking for updates
> > > to their own bits of software? Why on earth do I have a Printer
> > > Driver Update Manager? And I'd be wondering the same thing about
> > > a "Haskell installation manager": installation and dependencies
> > > are not something specific to Haskell.
> > why then do we have ghc-pkg, or cabal? surely the native package
> > managers should handle all that?
> > there are (at least) two dimensions of uniformity: across different
> > kind of software on a single kind of system, and with a single kind
> > of software across different kinds of system. platform-specific
> > package managers hide the software-specific notions of package
> > dependency maintainence, haskell-specific package managers
> > hide the platform-specific notions of package dependency
> > maintainence.
> > there is no need for platform- and haskell-specific tools to be
> > entirely separate or in conflict with each other: where both exist,
> > one can be a view on the other (if you are on linux-of-the-day,
> > you can use its package manage, independent of whether your
> > packages are haskell or lisp; and if you are using haskell, you
> > should be able to use its package manager, independent of
> > whether you are on unix-variant-of-today or on
> > unix-variant-of-yesterday).
> > there seems to be a lot of confusion here, some of us not
> > understanding the issues because we happen to be using
> > systems where "everything just works", others among us
> > not understanding the issues because we happen to be
> > using systems where "such things would never work anyway",
> > and yet others insisting on "i'll do it my way, so i know what
> > works" (and then, of course, there are those who are
> > actively working on improving the situation who will see
> > my criticism as constructive, i hope!-).
> > 1. there are no systems where "packages just work"!
> > there are systems where a few people ensure that
> > many people can live in such an illusion, though.
> Yes indeed! :-)
> > 2. systems with native package manager software still
> > need help from haskell-specific toolchains (unless
> > you want the human package managers on those
> > systems to code all haskell-specific dependencies
> > by hand).
> Yes. As an illustration: gentoo has an "haskell-cabal.eclass" that
> interfaces between ebuilds and cabal as the build manager and there
> is a tool to generate ebuilds that use the haskell-cabal.eclass
> from .cabal descriptions (so we get correct deps automatically).
> > 3. systems without native package managers (or perhaps
> > i should say: systems on which users with unix background
> > traditionally avoid getting acquainted with the details and
> > usage of whatever might pass as installation management
> > on those systems) are still in *very* wide-spread use,
> > and if haskell users on those systems are left out in the
> > rain, haskell developers will not be able to support those
> > systems. this limits the user and application base of haskell
> > on those systems, making haskell less relevant than it could be.
> Eg Windows, OSX, Solaris.
> > 4. haskell enables programming at a very high level of
> > abstraction, with fairly good support for mostly platform
> > independent code. but that code needs to be installed,
> > and integrated with dependencies and dependents, and
> > the integrated haskell installations needs to be maintained.
> > and that should "just work", even if the developer is on
> > (1;2) and the user is on (3), or vice versa, or if developers
> > and users are on different flavours of (1;2) or (3).
> > with these clarifications out of the way, my interpretation
> > of cabal was that it set out to provide two things
> > (A) a uniform platform-independent interface to such a
> > haskell package installation manager.
> > (B) a uniform platform-independent toolchain to support
> > such a haskell package installation manager.
> I guess so.
> > on systems in the (1;2) class, human package managers
> > would use (B) to integrate haskell packages into the native
> > package management software, so users might never even
> > encounter cabal.
> As in my example with the gentoo haskell packages above.
> > even so, (A) might offer a haskell-specific
> > view on the general platform package management (when
> > you want to see the haskell gui libs rather than all gui libs).
> > on systems in the (3) class, users and developers would
> > interface with (A/B) directly, for lack of a better alternative.
> > and developers/users in the (4) class would simply use
> > (A/B), without having to check whether they are "real"
> > or just a view on the platform-specific software. it is this
> > cross platform view of software development that i'm
> > most interested in (i'm one of those who use bash, vim,
> > opera, and haskell, no matter whether i'm on windows,
> > solaris, or whatever, and the cross-platform availability
> > of those tools has saved me many a headache;-).
> > returning to my earlier message, it seems that my
> > concerns were mainly these:
> > - it isn't sufficient to worry about installation management,
> > one has to worry about integration, lifetime and uninstall
> > management as well. in short, maintain the dependency
> > graphs over any of "install"/"upgrade"/"uninstall".
> For users in (1;2) class we would expect the native package manager to
> do this.
> > - for this to work, cabal needs to maintain not only
> > libraries as packages, but tools and compilers as
> > well. without this, some dependencies are not
> > recorded (this haddock depends on that ghc; to
> > build this package i need that tool; that tool was
> > built with this ghc version, from those sources, etc).
> > and if the dependencies are not even recorded, they
> > are likely to be broken if one does install/upgrade or
> > uninstall any haskell software, be it library, tool, or
> > compiler.
> Right. Currently cabal-install in its roll as a secondary package
> manager is very weak on that front. It does not record anything about
> what it installs. There's clearly plenty of work to be done there.
I'm wondering whether a hacked version of darcs could be used for
this. Together with sandboxing and support of alien packages,
it would already look like a full-fledged distribution... binary
packages could be a set of zipped darcs patches. Add USE-flag derived
dependencies and package and flag based stable/unstable marks and I'll
switch without hesition.
The question, IMHO, seems to be
"How would a package manager for a posix-compilant kinetic look like?"
I'd rather like a package manager to find them, rule them all and in
obsoletion bind them than attempting to hack around package managers *
PS: If you don't know why sandboxing is a MUST, read
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
More information about the Haskell-Cafe