[37344] branches/gsoc08-privileges/base/src/port1.0

[Rainer Müller]

Paul Magrath wrote:
> On 23 Jun 2008, at 21:29, Rainer Müller wrote:
>> Please use an appropriate way to find the home directory of the user
>> here, not an hardcoded /Users.
>>
>> There must be a better way to find the current user than an external
>> whoami. If you really need whoami, run it only once at a central  
>> place.
> 
> It is hardcoded in currently mainly for testing and development  
> purposes.

Okay. I would have expected some sort of TODO or FIXME there, just
to clarify that it is an intermediate solution which will be changed 
again soon.

> I'll be looking into finding a more reliable way of finding the home  
> directory of the user and I will definitely not be finding it more  
> than once. I'll use a global variable to store it once found.

Fine.

>> What happens if I run as root and this directory is not writeable?  
>> There
>> is no /Users/root (it would be /root) and an additional fallback is  
>> needed.
> 
> The idea would be that if run as root that privileges will be dropped  
> (see today's commit). I will be coming back to dealing with the  
> situation of a user running macports under su or having logged in as  
> root.

Right, we already discussed this shortly on a private mail. Just wanted
to bring an example to stress the need to use something like $env(HOME)
or to find the home directory.

>> And what if ~/.macports is not writeable?
> 
> Not sure why that would ever happen under normal circumstances tbh.  
> I'll add some code giving an explicit error message to the user though  
> to add to the Tcl permissions exception that would be generated.

Sure, it should never happen, but it could :-)
A program has always to take all possibilities into account, so an error
message would be preferred over a Tcl stack trace somewhere deeper in
the code.

>> The path ~/.macports should only be listed at one central place so  
>> it is
>> easier to change it later or customize it.
> 
> I'll use a global variable for this too.
> 
>> Also, I don't think there should be a warning to the user, just a  
>> message.

> Really? If any thing I was going to push that down to debug.

You could push it down to debug, but there is still the problem if you 
are running without sudo once and then with sudo. It will confuse users 
if port does do "unexpected" stuff, like starting build again from the 
start while it already build successfully to 
/opt/local/var/macports/build. A problem of the home directory approach, 
but I don't see an easy solution for it...

>> Why are you checking workpath for "~/.macports"?
> 
> There turned out to be no reason too. This was removed in my commit  
> earlier today.

Okay, didn't compared the changes yet, will do so. In fact the commit
from today motivated me to look at the older commit as well. Sorry for
the noise if this is already fixed.

>> There are ports consisting of more than just one Portfile (e.g. vim),
>> you need to copy files, too.
> 
> Will do. I'll have a look at the Vim port and see what needs to be done.

It uses includes to separate the huge checksum list (md5 checksums for
over 100 patches) from the Portfile and uses files/patchlist for it.

>> You still lock at the old place? I think this needs further  
>> investigation.
> 
> Em, no. I've changed the workpath so the statefile is now in the new  
> place.

Ah, sure.

>> Sorry for coming back to this commit so late.
> 
> No problem. Thanks for taking the time! I'll probably come back to you  
> again about one or two of these as well as the other stuff we've  
> discussed.

Don't hesitate. I think you are making good progress.

Rainer