Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?
Date: Mon, 30 May 2016 10:48:09
Message-Id: 20160530134753.137dff46089dae16f73f2abb@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess? by "Michał Górny"
1 On Sun, 29 May 2016 14:58:03 +0200 Michał Górny wrote:
2 > On Sat, 21 May 2016 11:19:07 -0400
3 > waltdnes@××××××××.org wrote:
4 >
5 > > On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote
6 > >
7 > > > I see the following possibilities:
8 > > >
9 > > > 1. We start explicitly listing linguas_* in all ebuilds, no matter how
10 > > > tiny they are. Maintainers are required to keep IUSE up-to-date
11 > > > and users are forced to rebuild a lot. This is also a QA violation
12 > > > in terms of invalid use of USE flags.
13 > > >
14 > > > 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
15 > > > miss and probably would need to repeated for every single phase anyway
16 > > > due to how global variables are handled in PMS. Additionally, it may
17 > > > break at some point since those variables are likely expected to be
18 > > > read-only anyway.
19 > > >
20 > > > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
21 > > > a good reason to use flags for localization, we introduce a new,
22 > > > non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
23 > > > with the new flag in their make.conf files. LINGUAS gets the original
24 > > > upstream behavior back, and we eventually discourage it in favor of new
25 > > > INSTALL_MASK features (WiP) [2].
26 > > >
27 > > > 4. We fix build systems not to do magic depending on whether LINGUAS
28 > > > is unset or set-to-empty. Instead, we could some special special value
29 > > > like '-' to signify not installing localizations at all. But that's
30 > > > upstream thing to do, and breaks backwards compatibility with existing
31 > > > systems disabling localizations.
32 > > >
33 > > >
34 > > > Your thoughts?
35 > >
36 > > 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
37 > > LOCALE_ALLOW="foo bar fubar"
38 > >
39 > > which would block installing files in /usr/share/locale/* and
40 > > /usr/share/man/* EXCEPT for...
41 > >
42 > > /usr/share/locale/foo
43 > > /usr/share/locale/bar
44 > > /usr/share/locale/fubar
45 > > /usr/share/man/foo
46 > > /usr/share/man/bar
47 > > /usr/share/man/fubar
48 >
49 > This can be accomplished using inclusion/exclusion logic included in
50 > the patches I've recently sent for Portage.
51 >
52 > INSTALL_MASK="/usr/share/locale -/usr/share/locale/foo"
53
54 A proper way will be to fix ebuilds to respect LINGUAS properly.
55 l10n.eclass makes this quite easy. Build and install files just to
56 remove them later before/after merge to a live system is ridiculous,
57 especially considering that LINGUAS covers not only manuals, but
58 also html docs and other files.
59
60 Why users should care about additional INSTALL_MASK ordeal if they
61 already set up LINGUAS properly? This is PM and ebuild maintainers
62 job.
63
64 The same states for cron, systemd, logrotate and other potentially
65 unneeded files. Install mask is dangerous, very dangerous, because
66 locations may move, mandatory files may have accidentally removed
67 by an oversight. INSTALL_MASK is indeed useful, essential tool and
68 it is nice that it is being extended, but it should be a last
69 resort way to fix stuff, not a recommended technique.
70
71 The real problem is that "small files" control creates much burden
72 for package maintainers. It should be fixed by versatile and easy
73 to use eclasses, ideally the most popular helpers should go to PMS,
74 e.g. to default src_install().
75
76 Moving all burden of "small files" control and optional cleanup
77 from developers to users is not nice.
78
79 Best regards,
80 Andrew Savchenko