[MacPorts] #50776: PortGroup/"base" extension suggestion : locale_select

[MacPorts]

#50776: PortGroup/"base" extension suggestion : locale_select
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by rjvbertin@…):

 Replying to [comment:6 ryandesign@…]:
 > Suppose a user wants to take advantage of this feature, but they have
 already installed a lot of ports. How will they do that?

 With a PortGroup-based approach only ports including the PortGroup would
 be concerned, but more generally speaking, the use of a variant to
 activate or deactivate pruning you'd have to reinstall the port(s) on
 which you'd like to apply it. Just like with any other port that you'd
 want to install with a different set of variants.

 There might be an alternative implementation where the pruning takes place
 in the pre-activate; if that's feasible you would be able to change the
 language selection without having to uninstall and reinstall; a simple
 deactivate and reactivate would suffice.

 Of course there is also the approach like the one taken by the KDE4 ports:
 provide translation (sub)ports. With KDE4 that means you install the
 translations into a given set of languages of *all* translated upstream
 projects. With KF5 it would probably be possible to make a semi-automatic
 separation of the main ports and a fixed set of translations for each of
 those ports. That does lead to a considerable explosion of the number of
 ports.

 > For example, we don't declare variants for every possible configure
 option; we make a best guess as to the features that would be helpful for
 most users, then provide variants for esoteric features that would require
 lots of extra disk space or dependencies.

 The difference here that we're talking about 1 single variant (or
 installation option if it were to be integrated into "base") which then
 allows the user to make a personal selection.

 > I worry that you will expand your request to add features for removing
 other aspects of ports that you personally don't need.

 No, not this particular request. And you could have understood by now that
 I only make requests or raise suggestions about things that I do myself
 when I think they're in the general interest. There's a lot that I keep to
 my own personal branch...

 > You could probably use those apps to prune the files installed by
 MacPorts. I'm not convinced we need to duplicate this feature in MacPorts.

 It wouldn't be hard to write something that throws out anything from
 `${prefix}/share/locale` that you'll never use, and such a script could
 easily be provided as part of a port with useful utilities. But in that
 case "base" should probably have a feature to prevent the sh*tload of
 warnings you get about missing translation files each time `rev-upgrade`
 is run.

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