[MacPorts] #45396: shared-mime-info @1.3 update-mime-database output is not removed on deactivate

MacPorts noreply at macports.org
Wed May 31 15:37:10 UTC 2023


#45396: shared-mime-info @1.3 update-mime-database output is not removed on
deactivate
-------------------------------+--------------------
  Reporter:  bgilbert          |      Owner:  RJVB
      Type:  defect            |     Status:  closed
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:  fixed             |   Keywords:
      Port:  shared-mime-info  |
-------------------------------+--------------------

Comment (by mascguy):

 Replying to [comment:23:ticket:67533 neverpanic]:
 > Replying to [comment:20:ticket:67533 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.

 One thought on this, albeit from a broader perspective: For configuration
 settings that are more likely to be changed, relatively benign, etc,
 perhaps we might want to consider providing a friendlier front-end to
 allow the user to both a) list them; and b) change them.

 Whether `startupitem_autostart` falls under the category of "things we'd
 like to expose and let users change," is another story.

 Regardless, it's the same idea as `git config xxx`: Let users see what's
 setup - at least for a few key ones - and let them update if they choose.
 (In our case, perhaps the verb might be `port prefs`, to avoid
 confusion/clashes with `port configure`.)

 Presumably you folks have already discussed this years ago, and likely
 already submitted a Trac enhancement request(s). Nonetheless, it's worth
 mentioning!

 Your folks' thoughts?

-- 
Ticket URL: <https://trac.macports.org/ticket/45396#comment:21>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list