Haiku, Inc. accepts contract relating to package management
As seen with the poll for the must-have features for R1, the lack of proper package management is clearly one of the items that are delaying the release of R1. More importantly though, as package management is an actual lacking feature (as opposed to a bug in an existing implementation), even the beta cycle is being blocked as a result. In order to progress, Haiku needs package management.
Despite some brain storming, an initial implementation of a PackageFSand the specification of its package format, little else has been done and much remains.
To help remedy this, Oliver Tappe has submitted a contract for 160 hours for a total of $2,622 USD. His efforts will center around doing the groundwork of getting package management actually started.
Specifically, this involves,
- evaluating various existing package management components, to determine if any make sense as part of Haiku's package management system
- evaluating the strengths and weaknesses of existing meta packages (e.g., apt, pacman, smart, ...,)
- evaluating if (and how) PackageFS can be used in conjunction with any of those meta packagers
These tasks could be seen primarily as a research based contract. While this is not a direct coding task, it is part of the development process. More importantly, is it work that is needed for R1 and this contract will allow it to receive some much needed attention.
The year 2010 has been a milestone in the project. The level of financial support reaching the project, (primarily as donations to Haiku, Inc., as well as to Haikuware Bounties, and the Haiku Support Association) has simply been overwhelmingly positive and encouraging. All of these contributions allow Haiku to be put on the fast track to R1. Thanks to all of you for showing your support!
If you appreciate this contract and would like to see more, please consider a donation to Haiku, Inc., as this will help to support the next contract. As always, Haiku, Inc. is eager to consider contracts for developing Haiku, even for non-C/C++ tasks that help pave the way towards R1.
Comments
Re: Haiku, Inc. accepts contract relating to package management
@fano
Windows uses the registry to keep track of installed programs, which is how applications know if it's already available. Do you want Haiku to have a centralised registry? I personally don't find the registry concept user-friendly, YMMV.
Glad you agree with me that "filesystem is the DB" is a good idea.
Re: Haiku, Inc. accepts contract relating to package management
No not registry, but package manager/installer must know in some way that libxyz is installed right?
Can be done with some sort of database (to note M$ registry is a sort of DB, in reality... but it was used for do the weirdest things... and became EVIL!), using Haiku filesystem (doing a search for all file with library attribute) or brutally searching in all known library dirs...
So Application xyz wants to install and has in its attribute set "depends on lib..." it simply ask to installer "it is satisfied"? YES... It starts! No, installer download lib(s) and then application start...
Re: Haiku, Inc. accepts contract relating to package management
@fano
Exactly, you're agreeing with my point, put the package management database information directly in the file system.
Re: Haiku, Inc. accepts contract relating to package management
I'm quite glad I haven't donated since 2008. I'd be pretty upset if any donations I've made might be paying for this. :( There are no outcome from it other than a comparison of linux package managers. Easy money for some.
Re: Haiku, Inc. accepts contract relating to package management
I agree with sparklewind. We should recognize that dependency sharing saves only minimal space these days compared to the capacity we have at our disposal.
If we examine our needs we can come to a compromise:
Each application that requires non-standard libraries, or a specific ABI version of a library, will have its own /lib structure.
The system will simply organize libraries according to their ABI version, in addition to the current model. ABI versions are major versions only, so not much fuss.
Example:
libdumbdum.so has three different ABI versions so that a new application written for version three will not work with version two, and one written for version one cannot work with version two or three...
To remedy this situation most libraries choose to have a unique file name, thus actually preventing dependency hell altogether... but we should ignore that...
We are assuming libdumdum.so has the same name regardless of ABI version...
So what we do, then, is "simple," but involves multiple parts of the system.
We modify the linker/compiler to include a hash of all non-standard libraries utilized by the program so we don't rely wholly on library developers.
We keep a database (online) of all these hashes and any corresponding library ABI versions ( and matching version numbers ) and a single copy of each ABI version of each library encountered that is installed into $common/config/lib during a system update.
We then use the package manager to acquire the correct library from this database, install to $common/config/lib/libname-ABIVER/file.
I don't like this way much at all, for what I hope to be obvious reasons ( like what to do about non-connected machines... ).
I would simply say to modify the compiler/linker to build a single package that encompasses all special dependencies into a single package.
This way doesn't save space, but it completely eliminates the problem - and not too many people will care about the extra few megs or so of space wasted on an average system.
The package manager will then create a system also for upgrading the application packages using a diff & a hash.
And, in the event disk space is low, we can search out the system for cloned libs and link them to a single copy stored in $common/libs/.clone
Would take much less work, would work better, and solves the problem.
This way our package manager offers Install, Upgrade, and Uninstall. And the install is nothing more than acquiring a single package and moving it to its final resting place on the system /users/$user/apps or under $common/apps. The package manager should also be capable enough to recognize when one user already has the same package installed and merely grab it from the system.
This prevents all needs for caching. The application package's meta-data could be used to recreate any package installer history database that would be created for performance sake.
Makes me wish I had time to code it up...
--The loon