It still needs a lot of refinement, but here is the ocaml febootstrap_pacman module if you are interested: http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap_pacman.ml;h=5076d85c76a428b7275b94c6c416c2694bfe6bd4;hb=HEAD
The more I look at it the more I see better ways of handling the situations presented in the module, as per usual, I love suggestions :) - oh, and I don't really know ocaml, I am learning it to make the port :) On Thu, Dec 9, 2010 at 12:33 PM, Thomas S Hatch <thatc...@gmail.com> wrote: > > > On Thu, Dec 9, 2010 at 12:14 PM, Xyne <x...@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 > >