Macports should be multiuser friendly

[ralph@…]

If macports is installed, it seems to assume that the user installing it is to be the only user - e.g. only that particular user's bash profile is edited to look for binaries in /opt etc.

I would like to use macports to install software for use in a teaching lab, where after I install some software, the software is available to each of my students under their own login names.

I'd like to ask the macports team to consider how to make macports work properly in a multiuser scenario like this, as well as for single user machines.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts should work fine in this scenario, provided users either type the full path to the programs they want to use, or add /opt/local/bin/ to their PATH.

[ralph@…]

That's none too friendly for a teaching lab. Students may have little idea of how to "add /opt/local/bin/ to their PATH". It would be much more helpful in such a case if macports software "just worked", for all users.

Also, it goes deeper than than you indicate. Various ports themselves tell users to make further updates to their paths, set various shell variables, etc. This is not going to be seen by the students if the class tutor installs the piece of software, nor is it necessarily useful to show it to them anyway.

It does seem that (1) some good way is needed of doing things transparently for all users - perhaps /etc/paths.d is part of the answer... (2) there needs to be some thinking of how to handle this in a systematic way right across macports, for all ports, (3) port maintainers are given guidelines on how to get this right, or better still, this is built into the macports infrastructure

This is why I am suggesting it as an enhancement request. It will need time and careful thinking to get right, but will make macports much more usable in classroom scenarios.

[neverpanic (Clemens Lang)]

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.

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.

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. 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. E.g.:

$> port user-configuration
There are 2 configuration changes you need to apply in order to run new software:
 1. dbus: load dbus user daemon
 2. kde-pimlibs4: update the system configuration cache
What do you want to do? ([Q]uit / [A]ll) A
1. The dbus port wants to: "load dbus user daemon"
  > launchctl load -w /System/Library/LaunchAgents/org.freedesktop.dbus-session.plist
  Allow? [y/N/never] y
  Success.
2. The kde-pimlibs4 port wants to: "update the system configuration cache"
  > kbildsycoca4
  Allow? [y/N/never] never
  MacPorts will not ask again about this configuration update.
No other configuration changes needed. Goodbye.
$> port user-configuration
No configuration changes needed.
$>

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.

[ralph@…]

Replying to 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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ralph@…:

(1) some good way is needed of doing things transparently for all users - perhaps /etc/paths.d is part of the answer...

We considered and rejected /etc/paths.d years ago. /etc/paths.d appends to the PATH; we want to prepend, not append.

It could possibly be addressed by having the MacPorts installer find all users' home directories and modifying all their .profiles; the installer does already have root permission to install MacPorts itself. However this wouldn't help for users that are created after MacPorts is installed. So is this the best solution, or is there another way that it could be addressed?

In any case, this request is already filed as #24930. Other specific change requests should be filed as individual tickets too.

Replying to ralph@…:

At the very least, there ought to be a how-to "How to setup up macports for multiuser scenarios".

Our wiki is editable by anybody and has a howto section; feel free to write such a how-to guide. Most of us don't use MacPorts in multiuser scenarios and so we probably aren't aware of the issues that you're encountering. If you're encountering an issue but aren't sure how to resolve it, you could leave part of the how-to unfinished and let other users fill in the details. You could enlist other users' help on the macports-users mailing list.

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

I don't think anybody needs convincing that this would be a good idea; I think we all agree on that. We just need to know exactly what aspects of MacPorts are inconvenient for multiuser scenarios, and how specifically those problems could be corrected by MacPorts.

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

I don't have first-hand experience with Linux package managers. How do they accomplish this, specifically? Perhaps we can adopt some of their techniques.

[ralph@…]

Replying to ryandesign@…:

Replying to ralph@…:

(1) some good way is needed of doing things transparently for all users - perhaps /etc/paths.d is part of the answer...

We considered and rejected /etc/paths.d years ago. /etc/paths.d appends to the PATH; we want to prepend, not append.

It could possibly be addressed by having the MacPorts installer find all users' home directories and modifying all their .profiles; the installer does already have root permission to install MacPorts itself. However this wouldn't help for users that are created after MacPorts is installed. So is this the best solution, or is there another way that it could be addressed?

It doesn't sound ideal, I must admit. There are files in /System which are copied across when a new user is created, and maybe these would need modifying too - but I'm not sure if that is exactly an approved approach...

In any case, this request is already filed as #24930. Other specific change requests should be filed as individual tickets too.

OK, but what is needed is a uniform approach for this that is part of macports infrastructure, not an adhoc solution for each bit of software that needs to do specific set-up operations for users.

Replying to ralph@…:

At the very least, there ought to be a how-to "How to setup up macports for multiuser scenarios".

Our wiki is editable by anybody and has a howto section; feel free to write such a how-to guide.

I don't have the expertise to do it, and anyhow, I don't believe this is the right approach, as it presumes the person who is writing it knows about every piece of software that needs specific setup, which is clearly infeasible. This is why it needs to be part of the infrastructure, not an afterthought hack.

I don't think anybody needs convincing that this would be a good idea; I think we all agree on that. We just need to know exactly what aspects of MacPorts are inconvenient for multiuser scenarios, and how specifically those problems could be corrected by MacPorts.

(1) At the basic level ports are currently usable by just the user who installed them. Ideally they would be usable by all users of the machine (unless a user specifically requests personal installation - but that is a second level of convenience probably best ignored for now).

(2) Some ports tell the user to set / modify various script variables. This should be done automatically.

(3) All of the above should work for existing and future users.

I really don't think the requirements are too hard to write down. Of course, that is not to say that there is a simple way to provide them.

"Ordinary" ports just need to make sure the software is on every users' path.

Ports which require more than this should be advised to do so in a standard way, where macports provides some infrastructure support for this standard way.

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

I don't have first-hand experience with Linux package managers. How do they accomplish this, specifically? Perhaps we can adopt some of their techniques.

I'm not a systems hacking guru either, so don't know, but that is a good suggestion.

[cooljeanius (Eric Gallager)]

Cc Me!

[st-macports.org@…]

Even just having a downloadable script or an option for the .pkg installer to only properly set the MacPorts path (without reinstalling the whole infrastructure) would be an improvement. Each time we add a user to a computer with MacPorts installed (about once every year I guess), I need to go searching for how to set their path appropriately. Often I end up resorting to running the complete MacPorts installer just to get the path set. Heck, make the script a package and then it could be invoked by giving it's entire path even for accounts that do not have the $PATH properly setup. I would love to add a user to the machine and then just fire up a terminal and invoke "/opt/local/bin/MacPortsPathSetup", or on a new MacPorts setup to be check a box on the installer to "install for all users" and have it be excecuted for each existing account on the machine.

• jb

[raimue (Rainer Müller)]

It is up to the user to make modifications to their environment (especially PATH) in order to use MacPorts. The installer contains the most common case, modifying the profile of the user running the installer. And even that only works if they are using the default shell. If you have more requirements, please set it up yourself. The ​guide even documents what you should add to .profile or .bash_profile.

If you run the installer instead of copying from the guide or from the configuration of your own user, you should first understand what this shell configuration does. If you prefer to use a script for that, why do you not just write it?

Furhermore, if you do not want to modify the shell configuration for every user, why do you not edit the system-wide configuration in /etc/profile or /etc/bashrc? MacPorts does not do this as these modifications would be lost on upgrades of OS X. As a system administrator you have control over that anyway and can follow your own documentation what needs to be changed on fresh installs/after upgrades.

As far as I know, the .pkg format is not flexible enough to allow selection of optional features. Even if, I would not know where we should add it system-wide as it depends on your use case.

[jmroot (Joshua Root)]

See also ${prefix}/share/macports/setupenv.bash

[raimue (Rainer Müller)]

It has been 6 years and we have not come up with any action to take for this ticket. As a last remark before closing, to add /opt/local/bin to your PATH system-wide, make the appropriate changes to /etc/profile.