[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
software.
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.
/Jonas.
Other related posts:
