[packagekit] Haskell packages

[Richard Hughes]

On Fri, 2007-11-16 at 01:19 +0000, Duncan Coutts wrote:
> Cabal packages also have metadata with all the usual stuff, like name,
> version and dependencies etc. There is a standard command line interface
> to configure, build and install a package.

Right. It sounds like a "backend" but specific to one application. I'm
not sure yet how that could slot into PackageKit in it's current design.

> Because we do not expect to have all packages available via the system
> package manager we have also created our own mini-package manager tool.
> It downloads builds and installs packages and their dependencies. We are
> currently mainly targeting per-user installs with this tool. It can do
> global installs too. Of course our users would prefer that it satisfy as
> many dependencies as possible by delegating to the native package
> manager, and only directly installing what is not available natively.
> This is obviously a bit tricky.

So, for instance if I need foo then your tools first look in the distro
package database and install that, or if not found download it from
HackageDB, build and install it? It sounds pretty clever. Are you
running the user tool as root?

One of the main design decisions from the start was to make PackageKit
only recognise per-system installs, rather than per-user installs. This
was done for the following reasons:

1) users might have different applications linking to different system
libraries
2) there's no real format for user-installs
3) security updates can't be applied to all instances of an install
4) session tools like gconf and dbus don't play nicely with locally
installed stuff in prefixes

So, PackageKit is only aware of a package_id per-system, and will
completely ignore user installed stuff. I still think it's useful to you
in this context as the packagekitd daemon runs as root and is hence able
to install stuff per-system, for all users.

> So there are perhaps two levels where it might make sense to integrate
> with PackageKit. One is to make a Cabal backend for PackageKit so users
> can have a nice UI to browse and manage installation of Cabal packages.
> The other is to get our cabal-install tool to ask PackageKit to install
> packages for us, to satisfy dependencies that are available through the
> native package manager (these might be Haskell packages or native C libs
> for Haskell libs that bind C libs).

Yes, this is very sane and can be done right now. If you look at
pk-install-package (in packagekit-gnome, just ignore the gtk bits) you
can see how easy it is to resolve a name to a package_id, and then
install that package_id if it's not already installed. I think it would
be a very good idea if cabal-install used packagekit in this way.

Plus, it also makes cabal-install cross-distro and cross-architecture
very easily, without any work on your part. I do think this
functionality is somewhat orthogonal to what you are asking below.

> So my question is how realistic does this seem? Could PackageKit work
> with a primary and secondary package manager? From a UI pov it might
> make sense to present secondary package managers as just different
> repositories. Of course, all this assumes that the secondary package
> manger behaves properly and doesn't tread on the toes of the primary one
> (like installing into /usr/local).

This needs thinking about. I don't want to feature creep, although I
know of other software that wants to do the same thing, for example
wine, managing the WIN32 software installed.

> >From a UI pov, package overlaps don't seem to hard, it's the same
> problem as having different repos. The problem is what to do when a
> secondary package needs a primary package.

Well, there would have to be compromises made, which is up to you to
decide if these compromises are too much :-)

PackageKit doesn't actually do _any_ dep resolution. It passes that to
the backends and lets them deal with all the complexity. What this means
is we can't to dep resolution over multiple backend instances, i.e.

Package Foo needs Bar

Install foo must mean that bar is installable via the same backend
instance, so if we used the yum backend then bar must exist in yum. What
can't happen is for the haskell package foo needs the yum package bar,
as the backends are completely isolated due to not doing dep resolution.
This is another design choice that can't change.

So, if we were to code a haskell backend, then we could get stuff in
packagedb installed into a system location, but it would not use the
distro packages. There's also the logical distinction between a repo and
backend type, as a backend can supply multiple repos, but at present
PackageKit can't have multiply loaded backend types.

This isn't to say it can't or shouldn't, it just complicates things. For
instance, if I choose to load the yum _and_ apt backends, then
get_repo_list() would have to query both and multiplex them together to
a coherent set of signals.

It also has the confusion of saying InstallPackage(foo) would also need
to know what repo to query and install from, as foo might exist in one
or the other, or even both. You could argue you could encode the backend
type in the package_id (which isn't insane, we already do that in 'data'
for the repo name) as this is just abstracted one step further. It just
means that Resolve and friends have to search in multiple instances
which would slow things down somewhat.

>From a logical GObject design of the daemon, quite a bit would also have
to change to support two or more loaded backends, and things get very
complicated very quickly. It could be done, but then we have quite a bit
of feature creep and functionality that is nearly impossible to
automatically test.

> Anyway, interesting to ponder.

Yes. :-)

Richard.