[aur-general] Augeas request

[Thomas S Hatch]

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
>
>