[MacPorts] #36323: Macports should be multiuser friendly

[MacPorts]

#36323: Macports should be multiuser friendly
--------------------------+--------------------------------
  Reporter:  ralph@…      |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  2.1.2
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by ralph@…):

 Replying to [comment:3 cal@…]:
 > Why don't you globally append `/opt/local/bin` to `$PATH` for all users?
 Surely you do have a mechanism to roll out configuration changes for all
 users? You could just add the file in `/etc/paths.d/` yourself.

 The problem is KNOWING what needs doing, not doing it per se. Macports is
 just one piece of software to be set up for teaching labs, and we cannot
 assume the administrator of the lab automagically knows that he needs to
 do this.

 At the very least, there ought to be a how-to "How to setup up macports
 for multiuser scenarios". But much better if macports does the setup. Then
 only ONE person has to do it - the macports maintainer, not many
 individuals running macports for labs etc.


 > Notes for ports can be shown by users using `port notes portname`, but I
 agree that often isn't helpful for users. The dbus port is a good example
 for that, since it requires users to load a launchd plist (one as root,
 one as user). I don't think MacPorts should attempt to add dbus to all
 users' configuration files — modifying a user's configuration should be
 left to the user.

 Agreed.  But macports should update some SYSTEM WIDE configuration files
 so that the user's config files are not touched AND the software "just
 works".

 > On (2) and (3), MacPorts currently does not provide a way to run
 commands at a user level. I agree this could be useful in some cases (like
 running kbuildsycoca for KDE apps or loading dbus), but doing this
 automatically might be surprising and unwanted.

 Not doing it is also surprising, and even more unwanted.

 > To go with the principle of least surprise, maybe MacPorts could offer a
 command to be run as user that will display what will be changed and ask
 the user whether he agrees to do this.

 If someone has asked to install some software, it is a fair bet that they
 are more worried about it not working if some config file is not changed,
 than worrying about config files being edited.

 Anyway, note that the whole point here is that we are trying to avoid per-
 user configuration, as we want the software to work for all users. The
 changes need to be made at a higher level, e.g. in /Library/Startup... not
 ~/Libarary/Startup... for example

 > You could then add the command to a user's shell startup files and
 they'll get prompted to run the update whenever there's changes available.

 This is just the thing I am suggesting macports should do, not the
 administrator.

 Please try to look at this from the point of view of the administrators
 and end-users

 End users want a system where they do not have to do anything, just type a
 command and it works. They do not want to be told when first logging in to
 edit some file they have never heard of (they may not know how to use any
 editor for example, if first year students).

 The administrators want to be able to install macports, and then type port
 install ..., whereupon the end users are left being able to run anything
 they have installed without any further interaction. Editing one or two
 system files to make this work is tedious. Trying to figure out what needs
 to be done so the end users get the behaviour described is non-trivial at
 the moment. This leads to the admins getting upset when I say "please
 install this for my lab" and they reply "I have to figure out all sorts of
 stuff and hack it to get it to work".

 Compare this to installing stuff on Linux - when you do that, it does work
 for all users, without such hackery.

-- 
Ticket URL: <https://trac.macports.org/ticket/36323#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS