> IMHO there should be *no* package that makes *anything* SUID root that 
> I (the user) don't know about, thus those packages that require 
> something like that should be modified on a per-package basis (for 
> these packages something like 'sudo make...' would work fine). 

True in principle, and good for experts, but I think that this would make 
life intolerable for some fraction of Fink users.  OS X has been quickly 
adopted in academic circles where people are used to using *nix because 
people can keep using the *nix applications they need, but all of the 
stuff that's typically painful when installing Linux on a laptop "just 
works" with OSX.  People wouldn't be happy about diving back into the 
minutiae of *nix administration.

> There could be three options (in my preferred order):
> 1) sudo to some other user (i.e. fink)
> 2) install as the current user.
> 3) sudo to root

Option 1 is nice in that it would prevent fink from clobbering system 
files, but it hasn't been my impression that this has been a problem.  For 
me, Option 1 has the serious drawback that it wouldn't solve the problem 
that I want user-mode fink to solve: I want to be able to build packages 
in a "sandbox" until I have the .info file debugged.  If fink always runs 
as the "fink" user and the whole /sw tree is owned by fink... I'm right 
back where I started -- my own .info files clobber the /sw tree until I 
have them fully debugged.

At this point I think it would be useful to consider _why_ user-mode fink 
is important and _what_ it's supposed to accomplish.  My opinion:

For users who never do anything but install packages, root-mode fink is 
fine.  It just doesn't matter if fink needs to be root for builds versus 
installs.  Eventually, it needs special privileges to do something 
useful, so just get permission at the beginning and be done with it.

For package maintainers, user-mode fink would be _very_ useful in that it 
will allow you to develop a new .info file without clobbering your own /sw 
tree (as happened to me).  I think that this is an important feature in 
recruiting new package maintainers.  If someone decides to try their hand 
at creating a package, the first few experiences are crucial -- if they 
trash their /sw tree by accident, they're not going to be inclined to keep 
trying.

Greg



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to