[RFC] Purpose and rigidity of librechroot/libremakepkg and related tools
The chroot package builder tools in Libretools is inflexible in many ways. Even if some of these are configurable or fixable, they are default behaviour:
- Hard-coded files. Examples:
- The complexity limits hacking to knowledgeable people.
As an example, the attached file shows a libremakepkg process tree. Building without a chroot only requires makepkg.
- clean-pkgs, which I believe runs every time before a package is built, removes chroot packages which are not (recursive) dependencies of the package to be built.
- There are no Libretools commands to make changes inside the master chroot, or it's not documented (librechroot -l could work).
- To build a package, the current directory must be in the abslibre tree controlled by Libretools. However, releasing packages does not allow uncommited files, so the tree can't be used for programming or testing.
I can recognize two different purposes of chroot package building tools like librechroot and libremakepkg: automation of package building on clean chroots, and validation of packages to respect packaging policy. Libretools seems to be focused on validation and following packaging policy, but not on providing clean chroots to aid the creation of packages. Maybe global validation/release and testing modes can be added to fill these separate purposes.
Updated by lukeshu about 6 years ago
There are no Libretools commands to make changes inside the master chroot, or it's not documented (librechroot -l could work).
That is the intended way to do it.
-l root. I guess I thought with the way the documentation was, that would be clear. What would be a good way of clarifying the docs?