- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
A brief summary of HAIKU's package management.
With the announcement of Ingo and Oliver's contracts for package management, it is worthwhile to revisit how package management will function. When reading, keep in mind that this explanation will be condensed, simplified, and partially incomplete. Nonetheless, it will provide a general overview on how things will work.
Each piece of software lives on the hard drive as a type of compressed archive. For this explanation, let us call that file a "package-archive". That package-archive contains directory information for all of its contents. As an example, the settings file goes here, the binary there, etc.
The package-archive is never decompressed onto the filesystem. Instead, Haiku gives the appearance that the package-archive is extracted. There is no mess of files being scattered about in obscure locations. In other words, a single package-archive contains the software itself, its associated data files, and a list of its dependencies. The dependencies themselves exist as individual package-archives.
There are many reasons to avoid including the actual dependencies (and their dependencies and those dependencies and so on) inside the package-archive. To give a very simple explanation, BeOS and Haiku are designed to be modular. Think of image translators. There is a single PNGTranslator which can be used by every program that uses Haiku's API. If a critical memory leak was found in PNGTranslator, every one of those programs would be affected (ShowImage, WebPositive, WonderBrush, slide show screensavers, ...). Once that bug gets fixed, instead of needing package maintainers to rebuild, repackage, and reupload all of those programs (and then for each and every end user to download and install all of the affected software), a user can simply install a new version of PNGTranslator and every thing is fixed. To put it simply, it would be blasphemous and completely against the design of BeOS and Haiku to suggest that every Haiku application include its own copy of PNGTranslator. This concept of "re-use as much as possible, in as many places as needed" extends to software dependencies, as well.
OK, back to the explanation ... As an example of installing software, let us imagine WebPositive was a separate download. At the moment, WebPositive requires Curl LibXML2 SQLite WebKit. Those dependencies require OpenSSL and XZ-Utils. (Don't believe me? See OptionalPackageDependencies)
There would be the following files:
* webpositive-<version>.package-archive
* curl-<version>.package-archive
* libxml2-<version>.package-archive
* openssl-<version>.package-archive
* sqlite-<version>.package-archive
* webkit-<version>.package-archive
* xz-utils-<version>.package-archive
For installing software, you can manually download and copy the package-archives into the watched directories --or-- you can use a guided process. (At this time, I'm not certain if that guided process will be available as a Haiku application or some type of website framework or both as options).
To install the software, webpositive-<version>.package-archive gets copied to one of several watched directories. Haiku determines which dependencies need to be installed. You will be informed of that and given the choice to either get them manually or to have Haiku get them for you. That's it, you're done.
To uninstall the software, simply move that compressed archive out from the directory. You can choose to completely delete the package archive or simply relocate it to a non-watched directory. That's it, you're done. (To note, the package system will even notice when there are packages that are no longer needed.)
For a complicated problem that many operating systems do not handle gracefully, this implementation sounds like the perfect fit for Haiku. There is no need to compile software, just to install it. There are no littering of your filesystem from installing software. It simply works.
- mmadia's blog
- Login or register to post comments
Comments
Re: A brief summary of HAIKU's package management.
Will it be possible to install multiple versions of the same software?
This is especially useful when you want to try out a newer version, so you can decide whether to adopt it for production. But until you are sure about it, you want to keep the old one.
Or also in cases ehen you simply want to keep both versions working on your system.
Re: A brief summary of HAIKU's package management.
Will it be possible to install multiple versions of the same software?
I suppose that depends on what you mean by the 'same' software, I'm certain you will be able to have different full versions, like SDL 1.2, SDL 2.0 installed simultaneously however those packages/libraries will be named differently.
If you are talking about downloading a development version of something then unless it's named differently I don't see how it would work having it installed alongside a previous package. That said, given how the package management is outlined as above by mmadia, you could simply move the 'old' version of the application/library package out of the 'watched' directory and move in the new version of the application/library, and then move the old one back again should you want to reverse the change.
Oh and great short description of the package system mmadia, seems like a great way to offer both manual (moving/deleting actual package files) management while I assume also offering a dedicated gui/cli application option.
Re: A brief summary of HAIKU's package management.
What about updating Haiku itself?
It would help testing and bug reporting/reproducing if user could easily update between nightly builds for example, without building code or reinstalling the system.
Re: A brief summary of HAIKU's package management.
[1] http://www.haiku-os.org/blog/bonefish/2011-06-20_package_management_syst...
Re: A brief summary of HAIKU's package management.
This sounds exactly how a package manager for Haiku should work. Simple. Elegant. Love it.
Re: A brief summary of HAIKU's package management.
So... since the packages are compressed is that with somthing fast like SquashFS without compression or will it slow down the startup of programs. If its mainly just packing the binaries better than BeFS can like SquashFS would do I expect it would acutaly speed things up.... I also remember someone mentioning that it might be possible to extract the packages into the filesystem perhaps to overcome those particular limitations.
Re: A brief summary of HAIKU's package management.
Afair running Haiku and apps from packages was not any slower than normal according to Ingo.
Btw check out the youtube videos on package management from BeGeistert:
https://www.youtube.com/watch?v=rNZQQM5zU-Q
Re: A brief summary of HAIKU's package management.
Related to the compression of the package, are you using the zlib to handle the compression? And if yes, do you support the different compression levels? IE. -0 does no compression but runs very fast vs all the way to the -9 compression level that is very slow but allows the max compression possible from the zip format?
-0 is great for max speed while still holding the package as a single file for easy handling, vs -9 allow greatly compressed but slow to access packages of limited storage mediums like CDs or smaller flash drives.
Related to above, another person asking how easy it is to remove the items from a package and installed into the basic file-system (IE real separate files). In my case I often like to move the fonts that come with certain programs and move them to a global access location so I can use the same fonts with other programs.
Re: A brief summary of HAIKU's package management.
-0 is great for max speed while still holding the package as a single file for easy handling
Well from what I understand, the package format itself works as a single file (which is virtually mapped as a directory) so there would be nothing to gain by using zlib on it with no compression, it's already a single file.
In my case I often like to move the fonts that come with certain programs and move them to a global access location so I can use the same fonts with other programs.
Judging by the proposal Ingo made in the mailing list, a gui based package creator program is to be made which I guess would then allow you to create/remove/add files to an existing package. So if there's a 'font' systems package you should be able to easily add any other fonts you want to that package and they will be available system-wide.
Perhaps it will be so transparent as to simply drag and drop a bunch of files onto a package in your file system and answer a verification question like 'do you want to add these files into package foo ?'