Thomas S Hatch wrote:
Ok, the process of building the libguestfs virtual machine image, called "supermin", must be executed as an unprivileged user during the libguestfs make process. The supermin build process is managed by a program called febootstrap, I had to write an additional module for febootstrap to support Arch - (and the upstream devs rewrote febootstrap to make it possible - because they are awesome). but since the make process needs to run as an unprivileged user febootstrap needs to download the required packages using pacman and then use tar to extract them into place.
I could get around it by heavily modifying febootstrap so that I can pass a third party repo into it that I maintain, but the libguestfs guys really don't want those patches upstream and it will make a real mess of things.
So what it boils down to is that the make process requires pacman, and only has access to the main repos, and there is only one package missing from said repos that is required - augeas.
-Tom
Upon closer inspection, the backdoor I was going to use to enable a third party repo has been removed from the upstream code, seems my "messy" option is no longer an option. I am still looking for another solution, but as of right now the inclusion of augeas in community is still the olny option I can see.
-Tom
Hi Tom, I'm curious about the febootstrap process. Is Pacman hard-coded in the module that you wrote? If it is, is there no way to generalize the process in such a way that it can call an external script based on the installation context and let that script handle everything itself? I understand that there is probably a good deal of complexity involved, but from the description it sounds as though the design could be improved (read: made more flexible). I wouldn't want to be the author of a project that requires considerable code changes in order to support different distros. It would require constant maintenance. It may well be unavoidable, but I would take it as a challenge to make it generic. Does the febootstrap process need to handle non-native architectures, i.e. does it need to be able to install binary packages that it can't build locally itself (if it were even possible to build the local packages). As a test case, I wrote a very small script that can retrieve binary packages from pacman or, failing that, build the binary package from the AUR and move it to the current directory, i.e. regardless of where the package is (repos, AUR), you end up with the binary package in the current dir. Obviously it's inherently dangerous as it blindly trusts the packages, but if you only need a few packages that you maintain yourself then it shouldn't be a problem. It's pure bash and very small (wc test.sh -> 28 87 731 test.sh) so I wonder if it could be worked into a general solution. There are, of course, several AUR helpers that could do the job, provided that the febootstrap could handle them and that the architecture limitation is irrelevant, but they would then become makedeps at least. Of course, augeas will probably get moved to [community] thus circumventing such concerns, but having a more flexible system would probably be better in the long run. /Xyne