Opened 18 months ago
Last modified 18 months ago
#67533 assigned defect
shared-mime-info @2.2_1: non sudo build clashes with sudo build
Reported by: | lukaso (Lukas Oberhuber) | Owned by: | neverpanic (Clemens Lang) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.1 |
Keywords: | Cc: | RJVB (René Bertin), mascguy (Christopher Nielsen) | |
Port: | shared-mime-info |
Description
This build fails without asking for sudo
access. And also fails because the existing plist
was placed there by a sudo
version of MacPorts.
There's also what feels like an anomaly with how the file is being installed in the first place.
I don't know what should be happening, but I think the ideal would be that the port let's the user know that to get the feature to launch automatically, a command needs to be run (with sudo
). (For my usecase, I don't need the plist
to be installed.)
---> Installing shared-mime-info @2.2_1 ---> Activating shared-mime-info @2.2_1 Error: Failed to activate shared-mime-info: error renaming "/Users/user/macports-gimp3-arm64/var/macports/software/shared-mime-info/mpextract07AJw27y/Users/user/macports-gimp3-arm64/etc/LaunchDaemons/org.macports.shared-mime-info-updater.plist" to "/Library/LaunchDaemons/org.macports.shared-mime-info-updater.plist": file already exists while executing "::file rename $srcfile $dstfile" (procedure "_activate_file" line 33) invoked from within "_activate_file ${extracted_dir}${src} $dest" ("foreach" body line 4) invoked from within "foreach {src dest} $confirmed_rename_list { $port deactivate [list $src] $port activate [list $src] [list $des..." ("try" body line 8) while executing "throw [dict get $eOptions -errorcode] [dict get $eOptions -errorinfo]" ("try ... on" handler line 5) invoked from within "registry::write { # Activate it, and catch errors so we can roll-back try { $port activate $imagefiles ..." Error: See /Users/user/macports-gimp3-arm64/var/macports/logs/_Users_user_macports-gimp3-arm64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_shared-mime-info/shared-mime-info/main.log for details.
$ ls -las /Library/LaunchDaemons/org.macports.shared-mime-info-updater.plist 0 lrwxr-xr-x 1 root admin 110 24 May 18:47 /Library/LaunchDaemons/org.macports.shared-mime-info-updater.plist -> /opt/local/etc/LaunchDaemons/org.macports.shared-mime-info-updater/org.macports.shared-mime-info-updater.plist
And looking at the /Library/LaunchDaemons
folder, things look a little bit odd (group is admin
instead of wheel
)
$ ll /Library/LaunchDaemons (gimp-2-10 $=) total 80 0 drwxr-xr-x 15 root wheel 480 28 May 21:53 . 0 drwxr-xr-x 68 root wheel 2176 8 Apr 02:45 .. 8 -rw-r--r-- 1 root wheel 627 28 Mar 08:44 com.docker.socket.plist 8 -rw-r--r-- 1 root wheel 1347 27 Mar 23:38 com.expressvpn.expressvpnd.plist 8 -rw-r--r--@ 1 root wheel 810 15 Apr 23:58 com.fing.service.plist 8 -rw-r--r--@ 1 root wheel 828 28 Mar 00:01 com.google.keystone.daemon.plist 8 -rw-r--r-- 1 root wheel 793 29 Mar 17:17 com.microsoft.OneDriveStandaloneUpdaterDaemon.plist 8 -rw-r--r-- 1 root wheel 749 29 Mar 17:17 com.microsoft.OneDriveUpdaterDaemon.plist 8 -rw-r--r-- 1 root wheel 428 17 May 00:40 com.microsoft.autoupdate.helper.plist 8 -rw-r--r-- 1 root wheel 657 12 Mar 12:45 com.microsoft.office.licensingV2.helper.plist 8 -rw------- 1 root wheel 271 11 May 14:04 com.microsoft.teams.TeamsUpdaterDaemon.plist 0 lrwxr-xr-x 1 root admin 90 16 Apr 17:57 org.freedesktop.dbus-system.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.dbus-system/org.freedesktop.dbus-system.plist 0 lrwxr-xr-x 1 root admin 74 1 Apr 23:58 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist 0 lrwxr-xr-x 1 root admin 110 24 May 18:47 org.macports.shared-mime-info-updater.plist -> /opt/local/etc/LaunchDaemons/org.macports.shared-mime-info-updater/org.macports.shared-mime-info-updater.plist 8 -rw-r--r-- 1 root wheel 622 28 Mar 17:30 us.zoom.ZoomDaemon.plist
Attachments (1)
Change History (28)
Changed 18 months ago by lukaso (Lukas Oberhuber)
comment:1 follow-up: 3 Changed 18 months ago by lukaso (Lukas Oberhuber)
comment:2 Changed 18 months ago by mascguy (Christopher Nielsen)
Cc: | RJVB added |
---|---|
Owner: | set to mascguy |
Status: | new → assigned |
Version: | → 2.8.1 |
comment:3 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to lukaso:
When I build MacPorts, I specify
--without-startupitems
as part of the call to./configure
but either that should be doing this and it's not working, or that applies to startup items for the MacPorts executables only.
Can you retest after setting the following, in either ${prefix}/etc/macports/macports.conf
or ~/.macports/macports.conf
. (I included the comments added by base, for clarity.)
# Type of generated StartupItems. # - launchd: Create StartupItems for use with launchd. # - default: Create StartupItems for launchd on macOS and none on # other platforms. # - none: Disable creation of StartupItems. # This setting only applies when building ports from source. startupitem_type none # Create system-level symlinks to generated StartupItems. If set to # "no", symlinks will not be created; otherwise, symlinks will be placed # in /Library/LaunchDaemons or /Library/LaunchAgents as appropriate. # This setting only applies when building ports from source. startupitem_install no # Whether to allow ports to automatically load their StartupItems. # If set to "no", StartupItems will never be loaded unless the user # explicitly requests it. If set to "yes" (the default), some ports may # automatically load their StartupItems when they are activated. startupitem_autostart no
comment:4 follow-up: 8 Changed 18 months ago by RJVB (René Bertin)
NB: this port is supposed to install its launchd plist and its functionality is crippled when that is prevented. Or will be crippled once all ports that install mime definitions start to rely on there being an automatic update of the mime cache (i.e. stop calling the updater themselves). In fact, we should probably have made that modification, or at least created a PR like the one for the cmake 1.1 PG to ask all port maintainers to make the change and test it.
@mascguy as you know I developed this with good-old-fashioned use of a hand-written plist, in which case the use of sudo
wasn't required (or only for the install and activate phases in case $prefix
required that).
I've been a proponent of not using sudo
for MacPorts myself but 1) too many ports have functionality that does require them to be installed in privileged fashion and 2) things go wrong too easily and thus too often when $prefix
has no protection at all (think things being installed in there instead of into $destroot
).
comment:5 follow-ups: 6 7 Changed 18 months ago by lukaso (Lukas Oberhuber)
Maybe this helps: homebrew
handles the same problem by having the user do the work when there are privileged things to be done (homebrew is not installed with sudo
).
It feels like it works and gets around some of the nasties.
Here's an example post install message:
def caveats <<~EOS Create the required host directories: mkdir -p ~/Library/Application\\ Support/Pow/Hosts ln -s ~/Library/Application\\ Support/Pow/Hosts ~/.pow Setup port 80 forwarding and launchd agents: sudo pow --install-system pow --install-local Load launchd agents: sudo launchctl load -w /Library/LaunchDaemons/cx.pow.firewall.plist launchctl load -w ~/Library/LaunchAgents/cx.pow.powd.plist EOS end
comment:6 Changed 18 months ago by mascguy (Christopher Nielsen)
Can you please test with the changes mentioned in comment:3, and tell me whether it fixes the issue?
comment:7 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to lukaso:
Here's an example post install message:
def caveats <<~EOS Create the required host directories: mkdir -p ~/Library/Application\\ Support/Pow/Hosts ln -s ~/Library/Application\\ Support/Pow/Hosts ~/.pow Setup port 80 forwarding and launchd agents: sudo pow --install-system pow --install-local Load launchd agents: sudo launchctl load -w /Library/LaunchDaemons/cx.pow.firewall.plist launchctl load -w ~/Library/LaunchAgents/cx.pow.powd.plist EOS end
That's less painful than running sudo port load <port_name>
? Seems pretty awful to me.
If they provided a script to do all of that, then fine. But asking a non-technical user to go through that? Yuck.
As for this specific case, building of GIMP doesn't require a daemon to be loaded: That's designed for end-users, who are constantly installing and uninstalling ports.
So test with the suggestions in comment:3, and please report back.
comment:8 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to RJVB:
NB: this port is supposed to install its launchd plist and its functionality is crippled when that is prevented. Or will be crippled once all ports that install mime definitions start to rely on there being an automatic update of the mime cache (i.e. stop calling the updater themselves). In fact, we should probably have made that modification, or at least created a PR like the one for the cmake 1.1 PG to ask all port maintainers to make the change and test it.
@mascguy as you know I developed this with good-old-fashioned use of a hand-written plist, in which case the use of
sudo
wasn't required (or only for the install and activate phases in case$prefix
required that).I've been a proponent of not using
sudo
for MacPorts myself but 1) too many ports have functionality that does require them to be installed in privileged fashion and 2) things go wrong too easily and thus too often when$prefix
has no protection at all (think things being installed in there instead of into$destroot
).
Rene, this is a very different situation, as the GIMP project is using MacPorts to build the macOS version of GIMP. Which is great! But it doesn't require daemon functionality.
So please, if you'd like to collaborate further on a longer-term approach, then let's discuss via the original ticket. But this simply muddies the waters for this case, which isn't typical.
comment:9 follow-ups: 10 12 Changed 18 months ago by jmroot (Joshua Root)
The Portfile is setting startupitem.install yes
, overriding what the user set in macports.conf. So multiple installations of the port in different prefixes will always conflict.
(It's also setting both startupitem.custom_file
and startupitem.create yes
, which makes no sense, but that's not relevant to this particular issue.)
comment:10 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to jmroot:
The Portfile is setting
startupitem.install yes
, overriding what the user set in macports.conf. So multiple installations of the port in different prefixes will always conflict.(It's also setting both
startupitem.custom_file
andstartupitem.create yes
, which makes no sense, but that's not relevant to this particular issue.)
Great points, I'll correct all of this ASAP tomorrow. Thanks Josh!
comment:11 Changed 18 months ago by lukaso (Lukas Oberhuber)
Having set all the variables above, it appears to install without problems.
When I then went to uninstall:
$ ~/macports-gimp3-arm64/bin/port uninstall shared-mime-info Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents. The following ports will break: gdk-pixbuf2 @2.42.10_0 gtk3 @3.24.37_1 Continue? [y/N]: y Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating shared-mime-info @2.2_1 Error: Failed to deactivate shared-mime-info: can't read "notes": no such variable Error: See /Users/user/macports-gimp3-arm64/var/macports/logs/_Users_lukasoberhuber_macports-gimp3-arm64_var_macports_registry_portfiles_shared-mime-info-2.2_1_69c9dfea6cbb502d01bec1aa2159ec5db0d6b2331c123e40bb82bddd6677a0d0-3054/shared-mime-info/main.log for details. Warning: Failed to execute portfile from registry for shared-mime-info @2.2_1 ---> Uninstalling shared-mime-info @2.2_1 ---> Cleaning shared-mime-info
Second try worked.
Then I installed the sudo
version and then installed the non-sudo
version and that succeeded as well. It looks like your fix worked.
That's less painful than running
sudo port load <port_name>
? Seems pretty awful to me.
I'm not familiar with this command. If that loads these things and the post install message suggested to do that (when doing a non-sudo MacPorts install), I think that's a pretty reasonable solution as well.
comment:12 follow-up: 14 Changed 18 months ago by RJVB (René Bertin)
Replying to jmroot:
The Portfile is setting
startupitem.install yes
, overriding what the user set in macports.conf. So multiple installations of the port in different prefixes will always conflict.
Is there a way to determine if the default for that setting has been changed by the user?
I'll admit that I didn't consider specific use cases like this but I do think that they shouldn't make things more complicated for the average J. User. Dev-teams using MacPorts to build their projects by definition have the know-how and means to take additional steps that Joe and Jane don't have...
The easy way out would be to provide a build variant that disables the auto-loading.
comment:13 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:14 follow-up: 21 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to RJVB:
Replying to jmroot:
The Portfile is setting
startupitem.install yes
, overriding what the user set in macports.conf. So multiple installations of the port in different prefixes will always conflict.Is there a way to determine if the default for that setting has been changed by the user?
I'll admit that I didn't consider specific use cases like this but I do think that they shouldn't make things more complicated for the average J. User. Dev-teams using MacPorts to build their projects by definition have the know-how and means to take additional steps that Joe and Jane don't have...
The easy way out would be to provide a build variant that disables the auto-loading.
Per Josh's point, the key is to not specify startupitem.install yes
. That way we defer to the user's configuration settings, which by default are set to auto-start these. (But in Lukas' case, it will be explicitly disabled.)
So there's no need for a variant. Does that make sense?
comment:15 Changed 18 months ago by mascguy (Christopher Nielsen)
Lukas, even though it sounds like everything works properly with your config settings, the latest revision should also eliminate the notes
error on uninstall.
comment:16 Changed 18 months ago by Christopher Nielsen <mascguy@…>
comment:17 follow-up: 19 Changed 18 months ago by neverpanic (Clemens Lang)
While MacPorts does have the capability to autostart launchd agents and daemons, very very few ports use this, and I would prefer if we kept it this way. So far, it seems net/wireshark_chmodbpf uses it (because without it, the port doesn't make sense), security/certsync uses it (again, the port doesn't make sense without it), sysutils/mpstats uses it (same reason, the user wouldn't have it installed if they didn't want the autostart), www/edbrowse uses it (but not to actually start the service, just to create a directory, it seems), and science/SDRplay3 uses it (I disagree with its use, it shouldn't auto-start, but it's not a commonly installed port, so I don't care).
You are now adding an autostarted item to a port that's commonly installed as a dependency. I really really don't want a random service to run just because something depends on shared-mime-info. Please revert the autostart.
comment:18 follow-up: 20 Changed 18 months ago by lukaso (Lukas Oberhuber)
I've selfupdate
d macports, but don't appear to be getting the new version. Will have to check at a later date.
For the record, I definitely don't want the port to autostart. dbus
is another port that seems to be creating a background task.
comment:19 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to neverpanic:
While MacPorts does have the capability to autostart launchd agents and daemons, very very few ports use this, and I would prefer if we kept it this way. So far, it seems net/wireshark_chmodbpf uses it (because without it, the port doesn't make sense), security/certsync uses it (again, the port doesn't make sense without it), sysutils/mpstats uses it (same reason, the user wouldn't have it installed if they didn't want the autostart), www/edbrowse uses it (but not to actually start the service, just to create a directory, it seems), and science/SDRplay3 uses it (I disagree with its use, it shouldn't auto-start, but it's not a commonly installed port, so I don't care).
You are now adding an autostarted item to a port that's commonly installed as a dependency. I really really don't want a random service to run just because something depends on shared-mime-info. Please revert the autostart.
If you review the prior ticket - issue:45396 - you'll see that none of this works properly without something monitoring the shared-mime-info
area. (At least not unless we add hooks in one or more other portgroups, to try and catch when things are added/removed. And that could be both fragile, and potentially error-prone.)
Furthermore, if you review the daemon itself, you'll see that it's based on a filewatcher. So it's not continuously doing things, until/unless the MIME area is touched. That's a very efficient way to do it.
Can you offer a better alternative, that ensures auto-updates to the MIME database?
Regardless, let's debate this via issue:45395, rather than this ticket.
comment:20 follow-up: 23 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to lukaso:
I've
selfupdate
d macports, but don't appear to be getting the new version. Will have to check at a later date.
Yes, it'll take at least two hours for the updates to sync.
For the record, I definitely don't want the port to autostart.
dbus
is another port that seems to be creating a background task.
That's the reason override settings like startupitem_autostart
exist in macports.conf
. Set those as you wish, and you're done.
comment:21 follow-up: 22 Changed 18 months ago by RJVB (René Bertin)
Replying to mascguy:
Per Josh's point, the key is to not specify
startupitem.install yes
. That way we defer to the user's configuration settings, which by default are set to auto-start these. (But in Lukas' case, it will be explicitly disabled.)So there's no need for a variant. Does that make sense?
Yes, and no. I agree with Clemens that most ports shouldn't autostart their launchd services. I'd say even DBus is among those (because it launches an actual daemon that provides services you might not want to have active).
This port is different, as you point out yourself. So yeah, I think it'd be preferable to not cripple it if users opt not to auto-start all launchd services, via a variant.
The alternative would be to provide some kind of level control over the kind of services you accept to have auto-started (a lot more complex) or simply not auto-starting anything when the activation isn't done with elevated privileges (both options would require rolling out). Using a dedicated env. variable would work too and will be less visible to common users.
comment:22 follow-up: 27 Changed 18 months ago by mascguy (Christopher Nielsen)
Replying to RJVB:
Yes, and no. I agree with Clemens that most ports shouldn't autostart their launchd services. I'd say even DBus is among those (because it launches an actual daemon that provides services you might not want to have active).
This port is different, as you point out yourself. So yeah, I think it'd be preferable to not cripple it if users opt not to auto-start all launchd services, via a variant.
The alternative would be to provide some kind of level control over the kind of services you accept to have auto-started (a lot more complex) or simply not auto-starting anything when the activation isn't done with elevated privileges (both options would require rolling out). Using a dedicated env. variable would work too and will be less visible to common users.
Sure, but MacPorts base supports this already, via config option startupitem_autostart
. So if a user doesn't want to auto-start things, they simply set startupitem_autostart no
in macports.conf
. (Either globally via ${prefix}/etc/macports/macports.conf
, or in their user-override config at ~/.macports/macports.conf
.)
comment:23 Changed 18 months ago by neverpanic (Clemens Lang)
Replying to lukaso:
For the record, I definitely don't want the port to autostart.
dbus
is another port that seems to be creating a background task.
The dbus port does not auto-start anything:
$ port notes dbus ---> dbus has the following notes: Startup items (named 'dbus-system, dbus-session') have been generated that will aid in starting dbus with launchd. They are disabled by default. Execute the following command to start them, and to cause them to launch at startup: sudo port load dbus
Even though some software will not work without dbus, we are not automatically starting a dbus-daemon for our users when the dbus port is installed, and I think this is the correct choice.
Replying to mascguy:
That's the reason override settings like
startupitem_autostart
exist inmacports.conf
. Set those as you wish, and you're done.
I think this is making things too simple on ourselves. Most users won't know that the setting exists, and only a few users will even bother to ask. Other users will be appalled by the decision to auto-start something on their machines, and silently leave, patch locally, or rant about it on social media. Our users should never even be in the situation where they need to consider setting startupitem_autostart no
in the first place. As a project contributor, I should have no incentive to set this option, and yet here we are and I just went and changed this setting on my system to prevent this from running automatically without my approval.
I was aware of this risk when I implemented startupitem.autostart
10 years ago (see #35474, r106810), and so far we managed to avoid using this in situations where it would surprise users, but it seems this is no longer the case. In fact, I regret building this.
comment:24 Changed 18 months ago by mascguy (Christopher Nielsen)
Well, if others would like to jump in and actively collaborate on this - with the emphasis on *actively*, meaning, actual work via a PR or whatever - then that's fine. But thus far, Yours Truly has been the only one collaborating with Rene on this.
But personally, I need to move on, and tackle the other 100+ tickets in my queue. So if any other MacPorts members would like to run with this, please feel free...
comment:25 Changed 18 months ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|---|
Owner: | changed from mascguy to neverpanic |
Clemens, given your strong opinions on this, I'll cede ownership to you.
comment:26 Changed 18 months ago by neverpanic (Clemens Lang)
I did post a few questions in https://trac.macports.org/ticket/45396#comment:18 to understand what the problem you're trying to solve actually is. If you have a few minutes, I'd appreciate your help there.
comment:27 Changed 18 months ago by RJVB (René Bertin)
Replying to mascguy:
Sure, but MacPorts base supports this already, via config option
startupitem_autostart
.
Is there a hole in our bucket? :) As I tried to convey, I find that all-or-nothing switch too coarse.
I just took DBus as an example as it had already been named and I had noticed it now uses the autostart feature when I (finally) upgraded my personal copy not long ago. Regardless of whether the daemon *can* be auto-started I can see how one would not want it to be. Nothing should be crippled if you only ever install a single runtime dependency of the DBus daemon, for instance (given how the daemon is for IPC).
FWIW, I don't see what's wrong with select ports starting this kind of service and above all I don't see why a single person would be able to ban such behaviour for the entire community.
I've given my opinion, offered a number of solutions for the case at hand (MP used *in* a build system), for the rest it's now blissfully out of my hands.
Trying to workaround by setting
echo 'startupitem_type none' | $dosudo tee -a ${PREFIX}/etc/macports/macports.conf
I'm getting the following, however the build continues (so workaround may be working):
When I build MacPorts, I specify
--without-startupitems
as part of the call to./configure
but either that should be doing this and it's not working, or that applies to startup items for the MacPorts executables only.