You know, this is one of the situations where I am kind of embarrassed I even brought this up. I can solve this problem much more cleanly with bacman, and it will clean up a number of aspects of the build process.
Ok, do me a favor, and next time I poke my head out, don't remember mas as a fool :) -Thomas Hatch On Thu, Dec 9, 2010 at 12:36 PM, Thomas S Hatch <[email protected]> wrote: > 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 <[email protected]>wrote: > >> >> >> On Thu, Dec 9, 2010 at 12:14 PM, Xyne <[email protected]> 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 >> >> >
