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.