Package Management: Bits and Pieces
The most notable one is probably that, with a few exceptions, I've repackaged all gcc 2 built optional packages that are are installed as part of the alpha build profiles. Their dependency declarations (and probably other package attributes) aren't correct yet, but other than that they are all proper HPKG files and placed in "common/packages" now. Consequently the "common" tree is also mounted via packagefs when booting.
Another item I've tackled is the build system update feature ("jam -q @myprofile update ..."), which broke with the introduction of package support. The feature allows to just build one or several files and replace them in the image, as opposed to rebuilding the whole image. Since almost everything lives in the system package now, that meant building the whole system package and replacing it in the image. After adding add/replace functionality to the "package" command and kneading the build system a bit, individual files will now be updated in a package and the package will be updated in the image. Probably not that fascinating for an end user, but my time for updating only a few components dropped from about 30 seconds back to significantly less painful 4 seconds.
I also had a first look at libsatsolver, which will likely become the library that will power our package dependency solver. API documentation for it is unfortunately non-existent. Luckily the sources come with an example program that basically seems to be a full-blown command line package manager with back-ends for RPM and DEB package and repository formats. I'll have to see how well the library will fit with our formats and how much it needs to be adjusted to satisfy our needs. That's definitely something I want to look into before my contract ends.
The other thing I'd like to look into -- and I think I'll even attack that first -- is the query support in packagefs. Initially I intended to postpone that until more of the infrastructure was finished, but I miss it a bit more than I thought. The implementation shouldn't be that complicated. Most of it can be recycled from the BFS sources. Merely the indices need to be written from the scratch and some glue code needs to be massaged into place.
- Haiku field trip report - January 2020
- Google Code-in 2019 finished
- No, I'm not Haiku's lead developer
- Haiku monthly activity report - 12/2019
- Haiku almost-monthly activity report - October and November 2019
- Haiku monthly activity report - September 2019
- Node.js now available in Haiku
- Haiku monthly activity report - 08/2019
- GSOC 2019 Final Report
- Haiku Activity Report: Performance Edition