On Thu, Dec 9, 2010 at 12:14 PM, Xyne <xyne@archlinux.ca> wrote:
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
I completely agree Xyne, flexibility is critical in theses realms of development. Originally libguestfs was developed for redhat and the problem of distro porting has long been inherently difficult, even getting the supermin appliance to build in the scope of koji (fedora/redhat package build system) was a serious problem. Originally porting it to Arch looked downright impossible, and I presented the same arguments you have presented here to the libguestfs team. They took the supermin build process and developed a way to support other distros, thus making it far more flexible. Right now to port this to another distro you need to write an ocaml module to support the package manager and distro. Honestly I had not considered scripting out that portion, and that would work, either to run the commands entirely in ocaml or to script them out. The more I mull this over the more I think it is viable to use the aur package, although I hope I don't need to as it adds extra complexity and like you say, if augeas is in community the problem is circumvented. I would still be interested in your script, I still lack a great deal of pacman fu! -Tom