[aur-general] Suggestions for dealing with packages that require root
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
On Thu, Dec 20, 2012 at 04:51:35PM +1100, Phillip Smith 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 ---end quoted text---
I'd just print explanatory message and error out, if group does not exist in system - people usually do not give root to package without (at least) reading AUR page anyway. -- My AUR packages - https://aur.archlinux.org/packages.php?SeB=m&K=AlexanderR
On 20 December 2012 17:45, <alexander.r@gmx.com> wrote:
I'd just print explanatory message and error out, if group does not exist in system - people usually do not give root to package without (at least) reading AUR page anyway.
There is already a 5 line warning in the PKGBUILD itself. You're suggesting just aborting if the user/group doesn't exist?
On Thu, 20 Dec 2012 16:51:35 +1100 Phillip Smith <lists@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
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.
On Dec 20, 2012 6:57 AM, "Steve Randall" <srandall52@fastmail.fm> wrote:
On Thu, 20 Dec 2012 16:51:35 +1100 Phillip Smith <lists@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
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.
On Thu, Dec 20, 2012 at 07:01:21AM -0500, Dave Reisner wrote:
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.
My suggestion would be to simply fail out if the user doesn't exist and have the user create the user himself. (Include the "sudo adduser something" that needs to be run in the error message for simplicity). AUR isn't supposed to be simple as in newbie-friendly but simple as in without cruft. Just my two cents. Allen
On 20 December 2012 23:01, Dave Reisner <d@falconindy.com> wrote:
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.
That would be ideal, but I don't have the time or skill to do that, especially at this time of year. Amanda is a fairly popular backup solution, I'm sure others more talented than I have investigated it and if they can't fix it, I don't like my chances of saving the day. On 21 December 2012 05:52, Allen Li <cyberdupo56@gmail.com> wrote:
My suggestion would be to simply fail out if the user doesn't exist and have the user create the user himself. (Include the "sudo adduser something" that needs to be run in the error message for simplicity).
That might be the best solution; it avoids anything having to run as root (makepkg and/or $HELPER), and makes it ample clear to the user what the situation is.
participants (5)
-
alexander.r＠gmx.com
-
Allen Li
-
Dave Reisner
-
Phillip Smith
-
Steve Randall