[aur-general] Augeas request

[Thomas S Hatch]

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