[Haskell-cafe] Re: cabal and platform-independent haskell installation management (again) (Re: Re: Ubuntu and ghc)

[Achim Schneider]

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 *
packages incompatibilities.

PS: If you don't know why sandboxing is a MUST, read
http://myeve.eve-online.com/devblog.asp?a=blog&bid=526

-- 
(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
signature prohibited.