[haiku-development] Re: software organization/installation

  • From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 15 Feb 2009 23:52:14 +0100 CET

Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
> time to discuss how software for Haiku should be:
> a) installed; an installer application (or not?)
> b) organized; where are files stored
> * Some people prefer to have an installer that 
>   is similar to the SoftwareValet installer.
> * Others prefer to manually copy files over to 
>   their system.

I dislike the current practice of simply dumping
the contents of all zips/packages in this huge 
spaghetti bowl we call the filesystem.

I don't believe in this can of worms style of 
software store. I think the use of a separate
package database is a weak design, which is likely
to get out of sync with the actual filesystem.

I don't see attributes as any better. It's too weak
to be the primary means to tell package contents apart.

I would like to suggest a package filesystem.
Ideally a filesystem that keeps packages intact
and separate, presenting them as the usual mixed
contents of unix-looking directories. /bin & Co.

This package fs could tag each file with a read-only
attribute stating in which package it's stored.

Given this, one could query for files within those
folders which don't belong to a package. This could
be useful, e.g. if you wanted to collect those files
and turn them into a package.

Packages could be zips or whatever, but ideally it
would be a dual-container where the outer format is
compressed and the inner format is uncompressed and
attribute-preserving. The outer is for distribtion
and is stripped when installed locally. (tar.gz-ish)

A package filesystem should present the contents
of these packages, intermixed. It could optionally
and additionally present each package by itself in
isolation. There could be a special folder and/or
a certain attribute that could signal package 
pathname conflict.

Even though the package filesystem itself should
be informative and usable, I think it would be wise
to have a manager application, providing the user
with more detailed advice on adding/removing/updating

Managing dependencies should not be part of the
package filesystem - that is something for the 
package manager - but the fs might be able to help,
possibly by exporting package dependencies.

The package manager would check dependencies and
conflicts and suggest solutions and updates.

BTW, I imagine that the metadata in packages gets
wrong once in a while, so I think there should also
be out-of-band dependency correction packages.

(These correction packages could be kept separate, 
as informative-only, or be used to irreversably patch
packages, leaving a package's payload and primary meta-
data intact (name, version, etc) while updating 
secondary metadata (dependencies) and finally add some
data to the package indicating by which update(s) it has 
been patched.)

A package filesystem was tried in one of the QNX 
releases. I don't know how it differed from what I've
tried to sketch here, and I don't why they dropped it.

With an increasingly huge software collection, I think
good organization is going to be paramount, and I also
think that install/uninstall scripts is a seriously bad
thing. (Do those still run as "root" in common Linuxes?)

Removing a package from a package filesystem should be 
close to atomic and much cleaner than the hit and miss
of sweeping a shared filesystem.

My two very oblong cents.


Other related posts: