bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The Hurdish Package Manager


From: Patrik Olsson
Subject: The Hurdish Package Manager
Date: Thu, 01 Apr 2010 18:27:13 +0200

Hello!

I recently read about the GSoC idea of "the Hurdish Package Manager". I
have a few ideas about one. Let's call it "abcpkg" for now since I
cannot find a better name (and the name "stow" is not appropriate for
it, I think).

Just a few words first about my experience with GNU/Hurd, Stow etc. I
have only tried running the Hurd two times, and the last time was more
than a year ago. Basically, my knowledge of Hurd is limited to what I
have read about it. I have thus never used stowfs, unionfs or anything
like that. But I do however regularly use GNU Stow in my home directory
on GNU/Linux.

Here's my idea:

The translator will use a work-directory (e.g. /var/abcpkg, or
~/.abcpkg) which it is discouraged to manually mess with (especially
when an abcpkg translator instance is using it and running). While
running, it will export an "interface-directory" somewhere
(e.g. /abcpkg, or ~/abcpkg), which is the user front-end interface.

The following files are exported in the interface-directory:

      * sources.list
      * activate.list
      * status/

The activate.list is the list of packages that you want activated.
Remove a line and the package and all dependencies that are now unneeded
goes away eventually, add a line and a package and its dependencies are
activated eventually. Dependencies that have been activated
automatically are _not_ listed in activate.list.

The sources.list lists all repositories you want to take packages from.
The format could probably be pretty much the same as in APT. The first
word in a line describes the repository type, e.g. "deb", "deb-src" or
"stow". The other words on the line are specific to repository type (but
usually it begins with an URL).

From this file, abcpkg will mount in its work directory what it needs
(http, ftp directories and so on). The simple "installation image"
format of traditional stow will also work by having "stow" as repository
type in sources.list. Perhaps extend this format by allowing the package
directories to contain dot-prefixed "hidden" files that contain
information about dependencies and so on.

When packages are activated, files from non-local repositories are
downloaded. They are extracted into the work directory and abcpkg will
make sure they appear in their target directories (with unionfs or
something, I guess). It's probably theoretically possible to link
directly to the repository mounts with a few archive/compression
translators between, but practically the performance would be awful (I
think).

The status directory contains read-only streams of messages from each
package being worked on (the activation of packages will happen
asynchronously).

Other ideas:

      * Being a base component of the system, it should not have any
        hard dependencies on lots of packages. It should be possible to
        use abcpkg without having Python, Perl and so on installed.
      * Make a backend for Debian repositories (so that "deb" and
        "deb-src" works in sources.list).
      * Is it possible to make status/ both a directory and a file so
        that it is possible to read all status messages at the same time
        by reading the status directory/file as a file? Or perhaps one
        could use a translator to merge any set of status files?
      * Save the state of the system. This could probably be done by
        simply making a copy of the activate.list file.
      * It should be possible to work with it even if the target system
        is not running (e.g. when installing the system from scratch, or
        if the system is too broken to run). This probably follows from
        the fact that abcpkg is not only used for system packages.
        However, repository specific limitations may apply.

Problems:

      * There need to be some way to handle if something invalid is
        written into the configuration files. Perhaps the write can fail
        with a custom error code?
      * Mixing repository types. Cross-repository dependencies.
        Conflicts, etc. etc. Trying to think about this makes my head
        hurt.
      * Debian packages are usually only meant to be installed in system
        directories. It will usually not work when installing them
        somewhere else (e.g. in the home directory).

C&C?

Note: I'm not planning to work on this. I just got the idea while
reading the GSoC project ideas and wanted to share. To be honest, while
I like the idea of letting a server asynchronously manage the packages
and using a Hurd translator for this, I don't think it's *that* much
more convenient or important. If I were to work on something for Hurd
(as a GSoC project or otherwise) it would be something more important,
like getting sound working, clean up code, or port Debian packages.
However, I don't think I have time for even that.

/Patrik

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]