[aur-general] Augeas request

[Xyne]

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