[aur-general] Suggestions for dealing with packages that require root

Dave Reisner d at falconindy.com
Thu Dec 20 07:01:21 EST 2012

On Dec 20, 2012 6:57 AM, "Steve Randall" <srandall52 at fastmail.fm> wrote:
> On Thu, 20 Dec 2012 16:51:35 +1100
> Phillip Smith <lists at fukawi2.nl> wrote:
> > Hi all,
> >
> > I'm after some suggestions for how to deal with packages (namely
> > amanda [1]) that require root to build. In this particular instance,
> > amanda needs the user/group that it will run under to be present at
> > compile time. Less than ideal, but that's what upstream gives us.
> >
> > At the moment, I check if the user/group 'amanda' already exist, and
> > if not, create them. This has the side effect that makepkg needs to
> > be run as root if the user/group doesn't exist. I then cleanup
> > (delete) the user/group at the end if I created them. That's messy
> > enough already, but it's been suggested that I use sudo to handle the
> > user add/delete parts to make the PKGBUILD friendlier to AUR helpers.
> > I know helpers needs to work with PKGBUILD's, not PKGBUILD's made to
> > work with helpers, but perhaps there is a middle-ground where we can
> > all eat our cake? ;)
> >
> > I don't want to include sudo as a makedepends since it requires
> > configuration to work properly, nor do I want to make the PKGBUILD
> > "intelligent" to try and auto-detect a privilege escalation tool
> > (sudo or su) which will lead to a bigger mess.
> >
> > Does anyone have a smarter/cleaner/easier way to deal with this
> > scenario?
> >
> > Cheers,
> > ~p
> >
> > [1] https://aur.archlinux.org/packages/am/amanda/PKGBUILD
> Maybe this would work? Create a separate amanda-user package whose sole
> function is to create the user on install and remove it on uninstall.
> Make it both a build and run dependency of amanda.

Please no. The AUR has enough cruft already.

To the OP, I suggest finding out what legitimately fails in the build when
the user doesn't exist and patching the build system to suck less. When
you're done, send your improvements upstream.

More information about the aur-general mailing list