1 |
On 07/25/19 04:14, Kent Fredric wrote: |
2 |
> On Thu, 25 Jul 2019 00:10:49 -0400 |
3 |
> desultory <desultory@g.o> wrote: |
4 |
> |
5 |
>> The user-side effects pf the proposal in question, were it to become |
6 |
>> policy, would be that anyone seeking to not install what is presently |
7 |
>> optional documentation would either be: |
8 |
>> (1) wasting build time and space (and, depending on implementation, |
9 |
>> dependencies) on their build system (potentially masking the files from |
10 |
>> being installed); |
11 |
>> (2) wasting the space in their installed image(s) (if they did not mask |
12 |
>> the files which would not currently be installed anyway); or |
13 |
>> (3) wasting their own time working around what the developers would be |
14 |
>> required by policy to implement by repackaging the software themselves |
15 |
>> to avoid the time and space drawbacks (though this would generally be |
16 |
>> expected to be a rather exceptional case, as it would be relatively |
17 |
>> extreme to avoid what would be a distfile and some file masking from the |
18 |
>> user side). |
19 |
> |
20 |
> Those concerns as per current policy is unrelated to the |
21 |
> dependency-control-of-USE issue presented here. |
22 |
> |
23 |
> Its already established not to use a USE flag to toggle building of man |
24 |
> pages if it doesn't require additional dependencies. |
25 |
> |
26 |
> These are _man_ pages we're talking about, not general purpose |
27 |
> documentation. |
28 |
> |
29 |
> End users who don't like man pages are encouraged to use the relevant |
30 |
> FEATURES to strip them from the installed image, or use INSTALL_MASK or |
31 |
> something. ( FEATURES=noman ) |
32 |
> |
33 |
> The GOAL here is to provide man pages in *all* circumstances, and, if |
34 |
> additional dependencies are required to build them, to ALWAYS install |
35 |
> them, or NEVER install them, and then, find a secondary way to obtain |
36 |
> man pages (prebuilt) |
37 |
> |
38 |
> The Total Cost of man pages as pure files on the target system is tiny, |
39 |
> and has practically no risk with regards to complexity. |
40 |
> |
41 |
> But the cost of *dependencies* has risk, and can inflate to complexity, |
42 |
> causing much more real problems for more users than a few kb of .1.bz2 |
43 |
> files. |
44 |
> |
45 |
> Hence, why we gate them with USE flags: Because it provides an out for |
46 |
> that complexity ( at the cost of giving a different kind of complexity, |
47 |
> and a reduction in utility if somebody has to opt-out to get around |
48 |
> that initial complexity ) |
49 |
> |
50 |
So, we more or less concur on those points, or are you attempting to |
51 |
convey some other meaning by restating points? |
52 |
|
53 |
> And hence why the counter-proposal to USE flags to solve that |
54 |
> complexity a different way is "prebuild them yourself and ship |
55 |
> them" ( as that eliminates all the dependency complexity and USE flag |
56 |
> complexity user side, while also giving them the man pages -> Quality ) |
57 |
> |
58 |
> Just the current mechanisms for this counter-proposal shift that |
59 |
> inescapable complexity to a place where it becomes harder to manage in |
60 |
> a standardized way. |
61 |
> |
62 |
Are you referring to a QA mandate to package or build man pages, |
63 |
regardless as a counter proposal to the status quo? If so, why? It is a |
64 |
proposal; the status quo is, at the risk of redundancy, the present |
65 |
state of things. |
66 |
|
67 |
> And I don't think shifting this complexity to maintainers is the right |
68 |
> step, even though I want the same deliverables. |
69 |
> |
70 |
> That's why I'd rather a way to shift this complexity to a build |
71 |
> service, ... albeit, it introduces some complexity of its own with the |
72 |
> building and distribution of these man pages. |
73 |
> |
74 |
As I have noted twice before in discussion of this proposal, such a |
75 |
build service once existed, and indeed could alternately be provided as |
76 |
a side effect of one or more of the tinderboxes still in operation, and |
77 |
could with some additional scripting automatically generate such packages. |
78 |
|
79 |
> Complexity is a pain-in-the-ass, you can't get rid of it, only shift it |
80 |
> around till it stops hurting. |
81 |
> |
82 |
> However, all that said, If we're going to shoot some kind of |
83 |
> documentation in the face for the pain its dependency-complexity |
84 |
> introduces, let it be "info". |
85 |
> |
86 |
> - Far fewer people enjoy or can actually get useful information out of |
87 |
> info pages |
88 |
> - Its build tooling frequently has dizzying problems in dependency |
89 |
> complexity and fragility, frequently made worse by portage getting |
90 |
> build ordering wrong after perl upgrades.[1] |
91 |
> |
92 |
> (Hopefully we've fixed the worst of that, but this is plutonium, a gift |
93 |
> that keeps giving cancer) |
94 |
> |
95 |
> 1: https://bugs.gentoo.org/buglist.cgi?quicksearch=texinfo |
96 |
> |
97 |
Since when is anyone proposing extirpating man pages on the whole? I am |
98 |
simply making the rather simple suggestion that pulling in more packages |
99 |
to support presently optional documentation as newly mandated |
100 |
documentation when such documentation is neither expected nor desired by |
101 |
the users of systems onto which it would be installed is not a net |
102 |
benefit to anyone. Even default on USE flags would be a better "fix" for |
103 |
the purported problem then making maintainers generate, package, and |
104 |
publish man pages themselves. |