[haiku-development] software management proposal
- From: Brecht Machiels <brecht@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2009 00:09:31 +0100
Hello,
Suppose we dare to attempt to use shared libraries as they were meant to
be used, I propose the following concept. I hope the schematic
representation is somewhat easy to read. I'm sure there are still some
(gaping?) holes in the concept, so please do correct me :)
Organization of installed software:
* application bundles similar to what MacOS provides
* each application is contained in its own directory (be it a mounted
bundle or not)
* includes libraries
* excludes drivers
* the bundles should be installable both system-wide and for a single
user (~ zero-install)
* some applications (ports) will need to know the absolute paths to
their data
* a user can not mount application bundles in the system-wide
application path!
* how do existing application bundle systems handle this (do any)?
* in AmigaOS, this could be solved by 'assigns' - does something
similar exist in Haiku?
("assign virt: phys0:directory/" creates a virtual volume that
points to the physical location phys0:dir/ - simular to a link)
* each application would simply have it's own virtual volume
(libabc-1.2-1: for example)
* unlike mounts/links, assigns are user-specific
* binaries (command line applications for one) will need to be added to
the path (remember, each application is contained in its own directory)
* add all the paths to PATH (shiver)
* or again, use a mechanism similar to AmigaOS's 'assign ADD'
("assign virt: phys0:dir1/" and "assign add virt: phys0:dir2/" will
create a logical volume that appears to the system as if it
contains the contents of both phys0:dir1/ and phys0:dir2/)
* when an application depends on a specific library, the software
management software will need to add the library's path to
LD_LIBRARY_PATH (which is specific for each application).
As this system can support multiple versions of a library, it does not
suffer from the discrete updates of the full trees as is the case in
your typical Linux package management system (eg. Ubuntu hardy,
intrepid, ...).
Of course, we can always have a go at such a "shared library" system for
free. When things don't work out, nothing is lost. We can always switch
to a "fat bundles" system. In fact, this transition will automatically
occur when problems arise :)
All in all, AmigaOS-like assigns would really make this a lot more
elegant, don't you think? :) This also reminds me. Is it possible in
Haiku to access archives as directories, as one could on AmigaOS using
(IIRC) 'handlers'? This would be a nice way to 'mount' bundles.
Distribution/installation of software:
* centralized software repository (let's call it HaikuBits for now)
* however, people should be free to provide packages separately
* the repository stores:
* the application bundle
* dependency information:
* libabc version >= 1.2 and optionally < 2.0
* perhaps specify preferred version
* build options! (for example: UCS2/UCS4 builds; Python, wxWidgets)
* as time moves on, this information may become outdated
* that is why it has to be stored in the repository
* specify additional rule: libabc version != 1.4
* based on user feedback
* dependencies:
* a dependency (one that satisfies the version and build options)
should be available from HaikuBits
* this way the package management software can automatically satisfy
the dependency
* if not, the author should include the dependencies in the bundle
or provide bundles for each of the dependencies
* developers can include all dependencies ("fat packages"), but this
should be discouraged
* a bundle is described by a unique name, and the version number, and
possibly a revision number (at least for ports)
* new versions of shared library bundles do not replace old versions
for obvious reasons
* there should be support for offline-installation of bundles
* bundles include the dependency information at the time of download
* HaikuBits should be able to create a 'superbundle' that includes an
application bundle and its dependency bundles
* top-level catergorization of software on HaikuBits should preferably
correspond to the categories in the leaf menu (plus adding some extra
categories such as 'libraries' and 'drivers')
I did not consider a pkgfs to not further complicate things. This might
be interesting however and should be investigated. I am not sure whether
a pkgfs would imply major changes to the above. If not, a pkgfs could be
'inserted' at a later point in time.
Kind regards,
Brecht
Other related posts:
- » [haiku-development] software management proposal - Brecht Machiels
