fink-core

[fink-core] How should we handle fink-bld?

[Alexander H. <ale...@gm...>]

Now that we've got master fink able to bootstrap, another question to
resolve before we do a release is how we bring in the 'fink-bld' user.

1) One option that has been mentioned (dmacks) is to append
passwd-fink-bld in the implicit BuildDepends for every package.  This is
currently done for 'dev-tools' as well.  One drawback is that our
10.5/10.6 passwd is still monolithic, so this means that all of passwd
will get installed (not just built) as soon as a user installs his/her
first package. On the plus side, we're not increasing the list of
"special" (built as part of the bootstrap operation but not Essential)
packages, and it will take but one additional line of code in
PkgVersion.pm to implement.

2) Another choice would be to strip the passwd-fink-bld stuff out of the
passwd package and let fink add its user in its own PostInstScript.
This would involve a lot more coding that option 1).  On the other hand,
we avoid installing all of passwd for all 10.5/10.6 users.

(aside:  I'm curious whether we can let individual packages handle
addition of their users rather than going through passwd.  Heck, they
can even _remove_ their user in a PostRmScript with a one-line call to
dscl, and we don't do that.)



If we were to go with option 1), I'd also recommend getting rid of the
blocking message that installing passwd produces, because it gives the
user the option not to install the passwd users and we definitely don't
want that.  (And we should change mentions of 'NetInfo' to 'Directory
Services' now that 10.4 is EOL'ed :-) )
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

Re: [fink-core] How should we handle fink-bld?

[David R. M. <dr...@fi...>]

On Apr 22, 2012, at 6:43 PM, Alexander Hansen wrote:

> Now that we've got master fink able to bootstrap, another question to
> resolve before we do a release is how we bring in the 'fink-bld' user.
> 
> 1) One option that has been mentioned (dmacks) is to append
> passwd-fink-bld in the implicit BuildDepends for every package.  This is
> currently done for 'dev-tools' as well.  One drawback is that our
> 10.5/10.6 passwd is still monolithic, so this means that all of passwd
> will get installed (not just built) as soon as a user installs his/her
> first package. On the plus side, we're not increasing the list of
> "special" (built as part of the bootstrap operation but not Essential)
> packages, and it will take but one additional line of code in
> PkgVersion.pm to implement.
> 
> 2) Another choice would be to strip the passwd-fink-bld stuff out of the
> passwd package and let fink add its user in its own PostInstScript.
> This would involve a lot more coding that option 1).  On the other hand,
> we avoid installing all of passwd for all 10.5/10.6 users.

Here's my 2 cents:

The reason we originally gave users the option of *not* allowing fink's passwd package to muck with the system (if they chose) is that fink is trying to avoid mucking with the system wherever possible, and this let some users opt-out of that particular system modification.

Now, I don't see how we can avoid (in the modern day and age) creating the fink-bld user.  But I don't see a compelling reason to take away the user's option to decline further system modification.

So I would be in favor of option #2, and leaving the passwd system largely untouched except for the special case of the fink-bld user.

  -- Dave

Re: [fink-core] How should we handle fink-bld?

[Alexander H. <ale...@gm...>]

On 4/22/12 3:54 PM, David R. Morrison wrote:
> 
> On Apr 22, 2012, at 6:43 PM, Alexander Hansen wrote:
> 
>> Now that we've got master fink able to bootstrap, another question to
>> resolve before we do a release is how we bring in the 'fink-bld' user.
>>
>> 1) One option that has been mentioned (dmacks) is to append
>> passwd-fink-bld in the implicit BuildDepends for every package.  This is
>> currently done for 'dev-tools' as well.  One drawback is that our
>> 10.5/10.6 passwd is still monolithic, so this means that all of passwd
>> will get installed (not just built) as soon as a user installs his/her
>> first package. On the plus side, we're not increasing the list of
>> "special" (built as part of the bootstrap operation but not Essential)
>> packages, and it will take but one additional line of code in
>> PkgVersion.pm to implement.
>>
>> 2) Another choice would be to strip the passwd-fink-bld stuff out of the
>> passwd package and let fink add its user in its own PostInstScript.
>> This would involve a lot more coding that option 1).  On the other hand,
>> we avoid installing all of passwd for all 10.5/10.6 users.
> 
> Here's my 2 cents:
> 
> The reason we originally gave users the option of *not* allowing fink's passwd package to muck with the system (if they chose) is that fink is trying to avoid mucking with the system wherever possible, and this let some users opt-out of that particular system modification.
> 
> Now, I don't see how we can avoid (in the modern day and age) creating the fink-bld user.  But I don't see a compelling reason to take away the user's option to decline further system modification.
> 
> So I would be in favor of option #2, and leaving the passwd system largely untouched except for the special case of the fink-bld user.
> 
>   -- Dave
> 

Option 2) wasn't that bad, as it turned out.  Anybody who is interested
can grab the "fink_creates_fink-bld" branch from github.  Or download it
from

https://github.com/fink/fink/tree/fink_creates_fink-bld

if you don't have a local copy of the fink repo.  I have fink generate
the fink-bld user during its PostInstScript if that user isn't present.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

Re: [fink-core] How should we handle fink-bld?

[David R. M. <dr...@fi...>]

On Apr 22, 2012, at 8:24 PM, Alexander Hansen wrote:

> On 4/22/12 3:54 PM, David R. Morrison wrote:
>> 
>> On Apr 22, 2012, at 6:43 PM, Alexander Hansen wrote:
>> 
>>> Now that we've got master fink able to bootstrap, another question to
>>> resolve before we do a release is how we bring in the 'fink-bld' user.
>>> 
>>> 1) One option that has been mentioned (dmacks) is to append
>>> passwd-fink-bld in the implicit BuildDepends for every package.  This is
>>> currently done for 'dev-tools' as well.  One drawback is that our
>>> 10.5/10.6 passwd is still monolithic, so this means that all of passwd
>>> will get installed (not just built) as soon as a user installs his/her
>>> first package. On the plus side, we're not increasing the list of
>>> "special" (built as part of the bootstrap operation but not Essential)
>>> packages, and it will take but one additional line of code in
>>> PkgVersion.pm to implement.
>>> 
>>> 2) Another choice would be to strip the passwd-fink-bld stuff out of the
>>> passwd package and let fink add its user in its own PostInstScript.
>>> This would involve a lot more coding that option 1).  On the other hand,
>>> we avoid installing all of passwd for all 10.5/10.6 users.
>> 
>> Here's my 2 cents:
>> 
>> The reason we originally gave users the option of *not* allowing fink's passwd package to muck with the system (if they chose) is that fink is trying to avoid mucking with the system wherever possible, and this let some users opt-out of that particular system modification.
>> 
>> Now, I don't see how we can avoid (in the modern day and age) creating the fink-bld user.  But I don't see a compelling reason to take away the user's option to decline further system modification.
>> 
>> So I would be in favor of option #2, and leaving the passwd system largely untouched except for the special case of the fink-bld user.
>> 
>>  -- Dave
>> 
> 
> Option 2) wasn't that bad, as it turned out.  Anybody who is interested
> can grab the "fink_creates_fink-bld" branch from github.  Or download it
> from
> 
> https://github.com/fink/fink/tree/fink_creates_fink-bld
> 
> if you don't have a local copy of the fink repo.  I have fink generate
> the fink-bld user during its PostInstScript if that user isn't present.

I had a further thought about this.  I think we should mark the fink package itself "BuildAsNobody: false".  That way, if there is some screwup and the postinstall script doesn't work, the user will still be able to try rebuilding fink.  Otherwise, we've potentially bricked their fink installation (as far as building things goes).

  -- Dave

Re: [fink-core] How should we handle fink-bld?

[Alexander H. <ale...@gm...>]

On 4/23/12 5:51 AM, David R. Morrison wrote:
> 

<snip>

> I had a further thought about this.  I think we should mark the fink package itself "BuildAsNobody: false".  That way, if there is some screwup and the postinstall script doesn't work, the user will still be able to try rebuilding fink.  Otherwise, we've potentially bricked their fink installation (as far as building things goes).
> 
>   -- Dave
> 

fink.info.in is already so marked in master.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

Re: [fink-core] How should we handle fink-bld?

[Dustin C. <dus...@us...>]

On Mon, Apr 23, 2012 at 12:43 AM, Alexander Hansen <
ale...@gm...> wrote:

> Now that we've got master fink able to bootstrap, another question to
> resolve before we do a release is how we bring in the 'fink-bld' user.
>
> 1) One option that has been mentioned (dmacks) is to append
> passwd-fink-bld in the implicit BuildDepends for every package.  This is
> currently done for 'dev-tools' as well.  One drawback is that our
> 10.5/10.6 passwd is still monolithic, so this means that all of passwd
> will get installed (not just built) as soon as a user installs his/her
> first package. On the plus side, we're not increasing the list of
> "special" (built as part of the bootstrap operation but not Essential)
> packages, and it will take but one additional line of code in
> PkgVersion.pm to implement.
>
> 2) Another choice would be to strip the passwd-fink-bld stuff out of the
> passwd package and let fink add its user in its own PostInstScript.
> This would involve a lot more coding that option 1).  On the other hand,
> we avoid installing all of passwd for all 10.5/10.6 users.
>

Another option is:

3) Keep fink-bld optional and rely on the existing fallback of building as
the standard OS X user "nobody." Using fink-bld could still be encouraged,
but at least people wouldn't be forced to modify their user database to
install fink. For example, the bootstrap script could have an additional
question in order to add fink-bld and yes could be the default and
recommended answer.

A key question is: what are the benefits of building as "fink-bld" over
building as "nobody"? I suppose that in theory fink-bld is more isolated,
but practically speaking, does it matter? On my computer, the only files in
/private and /usr which belong to "nobody" are a temporary folder, an empty
launchd plist, and the "locate" database (I didn't have the patience to
search the whole file hierarchy, but /private includes /etc and /var). An
errant build causing damage to any of these is not a significant concern.

Building as nobody is lightly tested compared to building as fink-bld. On
the other hand, adding fink-bld involves touching the user database, which
inherently more risky than running the compile scripts as "nobody."

I can see the argument that in some ways, it's simpler to just force
everyone to install fink-bld, but in other ways it's more complicated. If
fink-bld is optional, then there's no need to worry about making sure it
gets added during the upgrade from 0.32 to 0.33 and different ways that can
fail. There's no need to worry about the admittedly unlikely scenario of
the system already having a user with UID 266, and what would happen if
fink-bld gets added with the same UID.

I wasn't paying attention to fink development when --build-as-nobody was
introduced, so maybe it's clear to everyone else why "fink-bld" is much
better than "nobody." However, from my perspective, the discussion quickly
jumped to the mechanics of adding "fink-bld" without every discussing
whether it's really necessary. Maybe it is, but I just wanted to raise the
possibility of avoiding it.


Dustin

Re: [fink-core] How should we handle fink-bld?

[Alexander H. <ale...@gm...>]

On 4/23/12 6:15 AM, Dustin Cartwright wrote:
> On Mon, Apr 23, 2012 at 12:43 AM, Alexander Hansen
> <ale...@gm... <mailto:ale...@gm...>> wrote:
> 
>     Now that we've got master fink able to bootstrap, another question to
>     resolve before we do a release is how we bring in the 'fink-bld' user.
> 
>     1) One option that has been mentioned (dmacks) is to append
>     passwd-fink-bld in the implicit BuildDepends for every package.  This is
>     currently done for 'dev-tools' as well.  One drawback is that our
>     10.5/10.6 passwd is still monolithic, so this means that all of passwd
>     will get installed (not just built) as soon as a user installs his/her
>     first package. On the plus side, we're not increasing the list of
>     "special" (built as part of the bootstrap operation but not Essential)
>     packages, and it will take but one additional line of code in
>     PkgVersion.pm to implement.
> 
>     2) Another choice would be to strip the passwd-fink-bld stuff out of the
>     passwd package and let fink add its user in its own PostInstScript.
>     This would involve a lot more coding that option 1).  On the other hand,
>     we avoid installing all of passwd for all 10.5/10.6 users.
> 
> 
> Another option is:
> 
> 3) Keep fink-bld optional and rely on the existing fallback of building
> as the standard OS X user "nobody." Using fink-bld could still be
> encouraged, but at least people wouldn't be forced to modify their user
> database to install fink. For example, the bootstrap script could have
> an additional question in order to add fink-bld and yes could be the
> default and recommended answer.
> 
> A key question is: what are the benefits of building as "fink-bld" over
> building as "nobody"? I suppose that in theory fink-bld is more
> isolated, but practically speaking, does it matter? On my computer, the
> only files in /private and /usr which belong to "nobody" are a temporary
> folder, an empty launchd plist, and the "locate" database (I didn't have
> the patience to search the whole file hierarchy, but /private includes
> /etc and /var). An errant build causing damage to any of these is not a
> significant concern.
> 
> Building as nobody is lightly tested compared to building as fink-bld.
> On the other hand, adding fink-bld involves touching the user database,
> which inherently more risky than running the compile scripts as "nobody."
> 
> I can see the argument that in some ways, it's simpler to just force
> everyone to install fink-bld, but in other ways it's more complicated.
> If fink-bld is optional, then there's no need to worry about making sure
> it gets added during the upgrade from 0.32 to 0.33 and different ways
> that can fail. There's no need to worry about the admittedly unlikely
> scenario of the system already having a user with UID 266, and what
> would happen if fink-bld gets added with the same UID.
> 
> I wasn't paying attention to fink development when --build-as-nobody was
> introduced, so maybe it's clear to everyone else why "fink-bld" is much
> better than "nobody." However, from my perspective, the discussion
> quickly jumped to the mechanics of adding "fink-bld" without every
> discussing whether it's really necessary. Maybe it is, but I just wanted
> to raise the possibility of avoiding it.
> 
> 
> Dustin


We originally used the system's "nobody" user, but after some discussion
it was decided that there were potential risks associated with that
(which I can't remember offhand).

It was decided to set up our own unpriviliged user which had a low
probability of any upstream package using for anything.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/