|Version 21 (modified by 7 years ago) ( diff ),|
These are the TODO items for the Haiku Package Management.
- Prepare for use in a chroot environment. Currently it resolves the package directory path in the kernel I/O context. This is only a problem for packagefs mounted after chroot (low priority).
- Support packages being copied to the
packagesdirectory. Currently only moving works.
- Provide information about active packages to the tools that need it (e.g. the package solver).
- If necessary, add a caching mechanism to speed up mounting it.
- Before creating packages (e.g. the user guide), all files must be identified, since packagefs is read-only.
- Work on tools to build Haiku packages in a clean chroot environment.
- Status: There's a package management branch of haikuporter which builds HPKGs. It doesn't do chroot building yet (requires pkgman to solve dependencies and install packages) and probably should use another recipe format (e.g. RPM .spec files).
- Define packaging guidelines and create a tool to check packages those.
- Adjust build "recipes" for HaikuPorts packages as needed and build the packages.
- Status: There's a package management branch of haikuports with recipes for several packages already updated for building HPKGs.
- Implement the package solver (as Oliver proposed based on libsolv).
- Status: There's a WIP port of libsolv. It's more or less complete, but mostly untested (a reasonable amount of packages are needed to test it). The Haiku solver API is missing yet.
- Extend the package kit and the (CLI) package manager to support adding, removing, and updating packages. That probably also involves work on a server-side (i.e. repository) part.
- Implement a GUI package manager.
- Currently the stage 1 boot loader requires the stage 2 boot loader to be in the file
system/haiku_loaderon the BFS boot volume. Since the stage 2 boot loader itself should also be subject to package management, that means it currently the package manager has to extract it from the system package. It would be nicer, if the stage 1 boot loader could load the stage 2 boot loader directly from the system package. Since the space for the stage 1 boot loader is too limited to deal with the HPKG format (< 1 KB in total), the format would probably have to be extended to provide an easily accessible bootstrap code. Alternatively additional space for the stage 1 boot loader would have to be found/made in the BFS on-disk format.
Package/package repository format
- Remove B_HPKG_ATTRIBUTE_ID_PACKAGE_PROVIDES_TYPE ("package:provides.type"). The type is encoded in the name anyway.
- Add support for repository keys (public/private) and package signing/check sums, so that it is possible to verify that data retrieved from a repository have not been tempered with.
- Support compression for the whole heap instead of just for individual file data. This should improve compression rates especially for packages containing many small files with only a small drawback regarding removing/replacing files in packages (potentially the whole heap would have to be recompressed).
- Modify Expander to use a directory instead of the
expander.rulesfile. This way a package (like xz-utils or p7zip) can contribute a single file with the rules for its tools.
- Ticket: #8494
Note: See TracWiki for help on using the wiki.