[haiku-development] Re: software organization/installation

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 16 Feb 2009 19:45:34 +0100

Jonas Sundström schrieb:
Here's another go:

The package filesystem I tried to describe avoids:
- running scripts
- copying/moving/spreading files
- registering stuff
- mixing package contents

It would satisfy diverse needs:
- classic BeOS minimalism/simplicity
- control-freak information level
- scalable infrastructure (both up & down)

It could easily both co-exist and host
- normal app folders
- multi-location "unix file sprawl"
- Apple-style bundles (If Haiku had them you could
put a bundle in pkgfs package, if you wanted to.)

The pkgfs would monitor a folder on a "real" fs,
where packages are kept. That's the pkgfs backend.

It would present the package contents as a virtual
filesystem structure, possibly overlaying a real file-
system. (E.g. fully virtual: /apps/... or overlayed: /boot/apps/...) That's the frontend, and all there is
to it.

The pkgfs might also publish the metadata of each package, e.g. dependencies, as queryable attributes,
as a service to the packet manager and for user
perusal, should you be interested.

A pkgfs-aware "Add/Remove software..."-style app would
help enumerate installed software, present a list of
software available from the online repo, deal with dependencies and simply move packages to/from the pkgfs backend folder.

You could drag packages in/out of the packages folder
yourself - this would be perfectly workable with a small amount of software with few/no dependencies -
and the result should be obvious and instantaneous
in the apps folder.
(Problems could be signaled with attributes as well
as with icon overlays or badges, to cater to people
as well as to a package manager.)

You would get a package, from
- repo-aware application (Synaptic-style?)
- website
- USB/email
- some other Haiku box which had it installed already

When getting a package without the aid of the manager
application, you double-click the package to open/
install it with the manager app. Or you simply drop
it in the pkgfs backend folder.

Piece of cake.

It's not unthinkable to extend this also to ~/config/add-ons and /system/add-ons
for codecs, drivers, etc.
It's just a matter of fs overlay reach.
But I think it's best to keep the pkgfs' virtual
file structure somewhat apart from the boot fs,
and the user's "real" files, to avoid confusion.

The idea sounds interesting, but I am not sure whether there aren't any problems. In laymans terms, the pkgfs will "insert" fake files inside the real file system, which are really located inside packages, correct? What happens when two packages contain a file with the same name at the same location, but the actual file contents are different? It may look like the point of pkgfs to overlay the file depending on what application is being launched. But I don't understand how pkgfs can know who exactly is requesting the file at any given moment. It sounds like this needs to be runtime loader magic, but then the whole point of pkgfs seems to be moot, because the actual magic happens in the runtime loader anyways. I am probably missing something. :-)

Another interesting problem is installing software manually from source. How would that work? Would you require building packages instead of "make install"?

Best regards,
-Stephan


Other related posts: