From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C3AF8139694 for ; Sun, 23 Jul 2017 21:21:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 90BE7E0E85; Sun, 23 Jul 2017 21:21:03 +0000 (UTC) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.181]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4E4D8E0E7C for ; Sun, 23 Jul 2017 21:21:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C4BgAvEnVZ/6uQpUVcGwEBAQMBAQEJAQEBg1qBeIh/hgCQcywBlViCEoVBBAICg31CFgECAQEBAQEBAWsohRkBBTocMwsYCRMSDwUlNxuKFLB9izEBAQgCJoMoglN6hQWFN4J3gjEFkF2OcQKCKpFliy0ahn2UIIFEJQExgQqBAghJhzIkNoo2AQEB X-IPAS-Result: A0C4BgAvEnVZ/6uQpUVcGwEBAQMBAQEJAQEBg1qBeIh/hgCQcywBlViCEoVBBAICg31CFgECAQEBAQEBAWsohRkBBTocMwsYCRMSDwUlNxuKFLB9izEBAQgCJoMoglN6hQWFN4J3gjEFkF2OcQKCKpFliy0ahn2UIIFEJQExgQqBAghJhzIkNoo2AQEB X-IronPort-AV: E=Sophos;i="5.40,403,1496116800"; d="scan'208";a="321058671" Received: from 69-165-144-171.dsl.teksavvy.com (HELO waltdnes.org) ([69.165.144.171]) by smtp.teksavvy.com with SMTP; 23 Jul 2017 17:21:00 -0400 Received: by waltdnes.org (sSMTP sendmail emulation); Sun, 23 Jul 2017 17:20:59 -0400 From: "Walter Dnes" Date: Sun, 23 Jul 2017 17:20:59 -0400 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] vim-syntax USE flag Message-ID: <20170723212059.GA21609@waltdnes.org> References: <20170722220016.65f5b1cf@sf> <20170723174604.24212d4ad379cf2ec5917fc0@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170723174604.24212d4ad379cf2ec5917fc0@gentoo.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Archives-Salt: 37b9a1a2-85d8-442e-90cc-2f04c2a87af2 X-Archives-Hash: c559d46fdcea5db52b4943a8e23e0e26 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 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/ and /usr/share/man/*/man/. 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 I don't run "desktop environments"; I run useful applications