On Sun, Jul 23, 2017 at 05:46:04PM +0300, Andrew Savchenko wrote > On Sat, 22 Jul 2017 22:00:16 +0100 Sergei Trofimovich wrote: > > On Sat, 22 Jul 2017 16:27:39 -0400 > > Mike Gilbert <flop...@gentoo.org> wrote: > > > > > Packages currently handle installation of vim syntax support files > > > inconsistently. Some builds install the files if the "vim-syntax" USE > > > flag is enabled, while others install them unconditionally.
This reminds me of /usr/share/locale/*/LC_MESSAGES/<app-name> and /usr/share/man/*/man/<app-name>. There seem to be a lot of packages that are hardcoded by upstream to install umpteen locales of this stuff. > > > > > > Do these files fall into the "small text files" category for > > > unconditional installation? If so, we should probably phase out the > > > vim-syntax USE flag. > > > > I'd say use flag is not needed as long as it does not slow vim startup > > down by much and does not change editor behaviour for every single > > edited file type. > > The problem here is more complicated. What about 100 plugins from > different packages which of them is fast enough, but together they > are slowing vim down to unacceptable level? Such case is > especially sensitive on slow hardware. > > That's why fine control over vim files is mandatory. Yes, it > requires to rebuild packages, but with ccache/distcc available this > is not a huge issue. And if someone really want to avoid such > rebuilds, vim files can always be put to a separated package; > though I see no real reason to do this. > > Using INSTALL_MASK here is not an option, because toggling of > individual vim files using it will be a nightmare. A heavy-handed solution to the extra man pages and LC_MESSAGES stuff I mentioned above, is "localepurge". The file "/etc/locale.nopurge" contains a list of locales to *NOT* purge. LC_MESSAGES and man pages for all other locales are wiped. I'm not a professional programmer, but the following approach looks promising... Option A) A standalone program/script called "vimodulepurge" which would consult a file "/etc/vimodule.nopurge". The algorithm would be to "equery b" for each module in the module directory. If the owner of the module is not listed in "/etc/vimodule.nopurge", delete the module. Option B) Integrate this functionality into Portage. During the install process, check if the ebuild being installed is listed in "/etc/vimodule.nopurge". If not, skip installing files into the vim modules directory. If "/etc/vimodule.nopurge" doesn't exist, or "NEEDSCONFIGFIRST" has not been commented out, allow the modules to be installed. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
