[aur-general] Augeas request
Thomas S Hatch
thatch45 at gmail.com
Thu Dec 9 22:24:56 EST 2010
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
On Thu, Dec 9, 2010 at 12:36 PM, Thomas S Hatch <thatch45 at gmail.com> wrote:
> It still needs a lot of refinement, but here is the ocaml
> febootstrap_pacman module if you are interested:
> 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 <thatch45 at gmail.com>wrote:
>> On Thu, Dec 9, 2010 at 12:14 PM, Xyne <xyne at archlinux.ca> wrote:
>>> Thomas S Hatch wrote:
>>> > > Ok, the process of building the libguestfs virtual machine image,
>>> > > "supermin", must be executed as an unprivileged user during the
>>> > > make process. The supermin build process is managed by a program
>>> > > febootstrap, I had to write an additional module for febootstrap to
>>> > > 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
>>> > > needs to download the required packages using pacman and then use tar
>>> > > 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
>>> > > don't want those patches upstream and it will make a real mess of
>>> > >
>>> > > 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
>>> > > said repos that is required - augeas.
>>> > >
>>> > > -Tom
>>> > >
>>> > >
>>> > Upon closer inspection, the backdoor I was going to use to enable a
>>> > party repo has been removed from the upstream code, seems my "messy"
>>> > is no longer an option.
>>> > I am still looking for another solution, but as of right now the
>>> > 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
>>> 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
>>> let that script handle everything itself?
>>> I understand that there is probably a good deal of complexity involved,
>>> from the description it sounds as though the design could be improved
>>> 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.
>>> would require constant maintenance. It may well be unavoidable, but I
>>> 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
>>> I wrote a very small script that can retrieve binary packages from pacman
>>> failing that, build the binary package from the AUR and move it to the
>>> directory, i.e. regardless of where the package is (repos, AUR), you end
>>> 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
>>> 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
>>> such concerns, but having a more flexible system would probably be better
>>> the long run.
>> I completely agree Xyne, flexibility is critical in theses realms of
>> 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!
More information about the aur-general