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