[MacPorts] #50776: PortGroup/"base" extension suggestion : locale_select
MacPorts
noreply at macports.org
Fri Sep 2 00:55:11 PDT 2016
#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
More information about the macports-tickets
mailing list