On Fri 18 Jun 2010 09:37 +1000, Allan McRae wrote:
On 18/06/10 09:12, Loui Chang wrote:
On Fri 18 Jun 2010 08:19 +1000, Allan McRae wrote:
On 18/06/10 01:09, Loui Chang wrote:
Why not just take sudo and asroot out of the equation and treat makepkg as a real non-handholding executable?
What do you mean? Remove automatic dependency installation or require the entire thin to be run as root?
Enable the entire thing to be run as any user.
A user does not necessarily need to be called 'root' to have package manager privileges, nor do they need to be 'root' to have superuser privileges, so why do we need a special flag for when the user does happen to be 'root'?
I think a user should arrange those himself, rather than having makepkg assume that he wants to become root via sudo. If the user hasn't previously arranged the privs, then makepkg dependency installation should fail.
In my opinion any use of sudo, and any restrictions on root in makepkg should be removed. If you're keen to this idea I could provide some patches.
I still am not sure where you are going with this...
What I'm essentially saying is that makepkg shouldn't be the one managing privileges. It should be the users.
1) pacman requires you to be root to install packages (or at least UID=0 I think)
pacman -S pacman error: you cannot perform this operation unless you are root.
2) Doing the actual packaging as root is dangerous, especially if you have "make install" by accident in your PKGBUILD. Or, as does happen, the software has a shitty Makefile and ignores DESTDIR for part of the installation (for this reason --asroot is not being removed).
So we have conflicting needs within makepkg. root to install, non-root to build. When makepkg needs to install dependency packages, it checks if sudo is an option and if not falls back to using "su -c", and if that fails it gives up. Are you proposing that it just gives up straight away and not attempt privilege escalation?
Yes, I am proposing that. You can always drop to more restricted permissions to build if you are a worried superuser. It's an admin's duty to understand these precautions isn't it?