On 5/28/12 11:23 AM, Alexander Hansen wrote: > On 5/23/12 4:31 PM, Alexander Hansen wrote: >> On 5/22/12 10:04 AM, Alexander Hansen wrote: >>> On 5/22/12 1:53 AM, Dustin Cartwright wrote: >>>> On Tue, May 22, 2012 at 6:46 AM, Alexander Hansen >>>> <alexanderk.han...@gmail.com> wrote: >>>>> >>>>> Sorry, was in a bad mood. >>>> >>>> I was just trying to convince you to do less work, but I can see that >>>> I failed. :) >>>> >>>>> Here's the thought process I was working under: >>>>> >>>>> "fink configure" is a natural place to do anything that has prompts for >>>>> the user. However, it isn't supposed to have side effects, i.e. all >>>>> that it currently does is set up the fink.conf file. So I figured we'd >>>>> prompt for user input and do the sanity checking in "fink configure", >>>>> saving the results (FinkBldUid for immediate use, and AutoUid, >>>>> AutoUidMin, AutoUidMax for the next 'fink configure'), and then actually >>>>> write the fink-bld information (if required) elsewhere. >>>> >>>> To leave open the possibility of automatic UIDs replacing the current >>>> passwd in the future, would it be better to replace FinkBldUid with >>>> something more extensible? I don't know if the fink.conf parser can >>>> handle something like: >>>> >>>> FixedUids: << >>>> fink-bld: 266 >>>> postfres: 252 >>>> << >>>> >>> >>> I don't think fink.conf can handle that. >>> >>> >>>> Or maybe better would be just to take the UID and GID from >>>> %p/etc/passwd-fink and %p/etc/passwd-group if AutoUid is false? After >>>> all, this is where people were supposed to customized the added users >>>> in the past. >>>> >>>> Dustin >>>> >>>>> >>> >>> Actually, what it does right now is: >>> >>> 1) Check whether fink-bld exists on the system, and grab its UID and >>> GID--via 'id -P fink-bld'. That avoids worrying about whether the user >>> happens to have changed fink-bld's configuration by means other than >>> editing %p/etc/passwd-*, since we're using what is actually in place on >>> the system. >>> >>> 2) If fink-bld exists and is properly configured (defined as having both >>> a UID and GID) then the user is given the default option just to use the >>> extant fink-bld, regardless of whether AutoUid is set. That way they'll >>> be using whatever they had set up in the past, unless they specifically >>> make the change. >>> >>> For users without fink-bld, the default is to get an ID automatically >>> from the 600-699 range. >>> >> >> I've put something online at >> >> https://github.com/fink/fink/tree/fink_configure_sets_up_fink_bld >> >> Configure.pm is where things get configured to set. I check the >> validity of prospective UID/GID values here as well as in Services.pm. >> If there's a pre-existing fink-bld user, it gets used by default, and >> its UID/GID (assumed to be the same) get stored in fink.conf. >> >> Services.pm has similar changes to what Dustin added in his branch, with >> a few tweaks. In this case, the FinkBldUid: field from fink.conf takes >> precedence over the current UID/GID of the fink-bld user, so if they >> differ the assumption is that the user wanted to change to the fink.conf >> value. >> >> Engine.pm actually runs &ensure_fink_bld() thereby setting the fink-bld >> user up. It checks for every fink verb other than "configure". We may >> want only to do that for build operations, perhaps--though it was >> convenient just to use "fink index" to test changes to the fink-bld >> user. :-) >> >> I'm not sure if everything is compliant with how things need to be set >> up when users are managed e.g. via OpenDirectory. > > OK, I think we may be close to ready for the 0.33.0 release. In > addition to making --build-as-nobody the default build mode and > recognizing 10.7.4: > > 1) Unless I get an objection within a few days, I'm going to merge into > master https://github.com/fink/fink/tree/system-python which makes > %p/Library/Python a directory recognized by the validator, and which > disallows use of PYTHONPATH containing a system-global Python library > directory (the aforementioned %p/Library/Python, > %p/lib//sw/lib/pythonX.Y/site-packages). > > 2) Unless I get an objection within a few days, I'm going to merge into > master https://github.com/fink/fink/tree/xcode_app, which changes the > "xcode" virtual package to indicate installation of and the version of > the Command Line Tools for Xcode 4.3+ rather than the version of > Xcode.app; and which introduces an "xcode.app" virtual package whose > version is the version of Xcode.app (the 'xcode' and 'xcode-app' > packages carry essentially the same information for Xcode 4.2.1 and > earlier). > > 3) And I'd like to merge into master > https://github.com/fink/fink/tree/fink_configure_sets_up_fink_bld, which > sets up the fink-bld user via "fink configure" and activates/checks it > on build-relevant operations. If you can only check out and evaluate > one branch this summer, this is the one!
I've merged all 3 of these into the official master, and I plan to release 0.33.0 on June 7. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
