[aur-general] Augeas request

[Thomas S Hatch]

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 <thatch45 at gmail.com> 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 <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,
>>> 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
>>
>>
>