Please test branches/release_2_0 with Xcode 4.3
Clemens Lang
cal at macports.org
Sun Feb 26 07:41:51 PST 2012
On Wed, Feb 22, 2012 at 03:08:57PM +0100, sierkb at gmx.de wrote:
> This supposes/implies further, that this _current_ user, who has to
> generate this particular com.apple.dt.Xcode.plist file has to be an
> admin user with privileged rights (admin). Because only this admin
> user with privileged permissions, per default is able to successfully
> run sudo and therefore is able to successfully is able to run macports
> via 'sudo port install…'.
Unless the user would use a non-root install of macports, which always
copies the plist from his home directory.
> As far as I understand the current state, the admin user is _forced_
> to run Xcode 4.3 at least once to let create it a
> com.apple.dt.Xcode.plist file in the admin's preferences directory.
> BUT: what if the user intentionally doesn't want to do that, wants to
> avoid that (for instance to avoid creation of unused files under an
> account he anyway never uses while working with Xcode) and
> intentionally wants to restrict this step to his preferred
> _un_privileged standard user, who later runs and uses Xcode 4.3 anyway
> on a regular basis?
The user running `port install something` is the user using xcodebuild
and therefore the user that should have accepted the terms and
conditions. If you really want to work around this, you can
(1) just copy the plist file to the privileged user's home
(2) run sudo xcodebuild -license and accept the license globally
> What, if Xcode 4.3 is only installed/copied into its default location
> in /Applications by an admin user with privileged rights/permissions,
> but intentionally _NOT FIRST RUN_ and _NOT RUN_ later by this admin
> user? And only _FIRST RUN_ and _RUN_ and _used_ by an _un_privileged
> user (standard user), who doesn't run macports (because macports only
> is run only after role changing into admin's role and then run via
> sudo)?
In this case the user running macports (the admin user) has not accepted
the license agreements and should thus not be able to run xcodebuild (by
Apple's expectations). I don't think we should work around this.
> Wouldn't it be better to search for the existence of a
> com.apple.dt.Xcode.plist file not only in the _active_ user's
> preferences directory (admin user), but as well as in at least one
> more second (or all) unprivileged user's (standard user) preferences
> directory to fetch for a com.apple.dt.Xcode.plist file in case of no
> existence of this file in admin's user directory? So, wouldn't it be
> better to loop through _all_ existing users preferences directories
> below /Users to catch minimum one com.apple.dt.Xcode.plist file which
> will then be copied into macports' own new home directory?
Imagine a multi-user system and macports looping through the home
directories, getting the required plist. Are you saying we should use
any users' acceptance of the terms and conditions for all macports
action going on in the system regardless of who actually uses macports
(and thus xcodebuild)?
Let there be two completely unrelated users A, B. A has accepted the
terms and conditions, while B has not. Now, if B ran sudo port install
something, should we really just use A's acceptance of the terms to
build the port B actually is building?
--
Clemens Lang
GSoC Student
More information about the macports-dev
mailing list