shared-mime-info @2.2_1: non sudo build clashes with sudo build

[lukaso (Lukas Oberhuber)]

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

[lukaso (Lukas Oberhuber)]

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):

--->  Fetching distfiles for shared-mime-info
--->  Verifying checksums for shared-mime-info
--->  Extracting shared-mime-info
--->  Configuring shared-mime-info
--->  Building shared-mime-info
--->  Staging shared-mime-info into destroot
--->  Installing shared-mime-info @2.2_1
--->  Activating shared-mime-info @2.2_1
Error: Failed to load shared-mime-info: Launchd plist /Library/LaunchDaemons/org.macports.shared-mime-info-updater.plist was not found
Error: Failed to load shared-mime-info

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.

[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

[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).

[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

[mascguy (Christopher Nielsen)]

Can you please test with the changes mentioned in comment:3, and tell me whether it fixes the issue?

[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.

[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.

[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.)

[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 and startupitem.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!

[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.

[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.

[Christopher Nielsen <mascguy@…>]

In 52357adb0f8a21112dc6c774aacf547bffc2eec9/macports-ports (master):

shared-mime-info: startupitem: don't set autostart, create, install

• Let user's configuration settings drive behavior
• Misc cleanup: don't set use_xz; already enabled by gitlab pg

See: #67533

[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?

[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.

[Christopher Nielsen <mascguy@…>]

In e5a3002c66d642edfd00d53465316c3818e0a72b/macports-ports (master):

shared-mime-info: startupitem: re-enable autostart

• Needed to ensure item starts by default, if not explicitly blocked by user config

See: #67533

[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.

[lukaso (Lukas Oberhuber)]

I've selfupdated 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.

[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.

[mascguy (Christopher Nielsen)]

Replying to lukaso:

I've selfupdated 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.

[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.

[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.)

[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 in macports.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.

[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...

[mascguy (Christopher Nielsen)]

Clemens, given your strong opinions on this, I'll cede ownership to you.

[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.

[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.