| 1 |
On 07/24/19 10:40, Kent Fredric wrote: |
| 2 |
> On Tue, 23 Jul 2019 23:56:52 -0400 |
| 3 |
> desultory <desultory@g.o> wrote: |
| 4 |
> |
| 5 |
>> avoid optional documentation, |
| 6 |
>> while the proposal in question explicitly would |
| 7 |
> |
| 8 |
> I assume you meant 'optional dependencies' here right? :) |
| 9 |
> |
| 10 |
The user-side effects pf the proposal in question, were it to become |
| 11 |
policy, would be that anyone seeking to not install what is presently |
| 12 |
optional documentation would either be: |
| 13 |
(1) wasting build time and space (and, depending on implementation, |
| 14 |
dependencies) on their build system (potentially masking the files from |
| 15 |
being installed); |
| 16 |
(2) wasting the space in their installed image(s) (if they did not mask |
| 17 |
the files which would not currently be installed anyway); or |
| 18 |
(3) wasting their own time working around what the developers would be |
| 19 |
required by policy to implement by repackaging the software themselves |
| 20 |
to avoid the time and space drawbacks (though this would generally be |
| 21 |
expected to be a rather exceptional case, as it would be relatively |
| 22 |
extreme to avoid what would be a distfile and some file masking from the |
| 23 |
user side). |
| 24 |
|
| 25 |
Developer-side effects of the proposal in question would explicitly |
| 26 |
force developers to use bespoke workarounds to avoid adding optional |
| 27 |
dependencies to packages, for questionable gains. |
| 28 |
|
| 29 |
So, while I was commenting on user-side effects, the phrasing applies to |
| 30 |
developer-side effects given s/documentation/dependencies/. |
| 31 |
|
| 32 |
As I have noted elsewhere, there is a solution for which the majority of |
| 33 |
the tooling exists which could achieve the same ends as the proposal in |
| 34 |
question without causing developers in general significant additional |
| 35 |
overhead beyond the status quo, while as a side effect providing |
| 36 |
additional services to users. However, the proposal in question |
| 37 |
specifically avoids offloading the newly generated work to automated |
| 38 |
systems in favor of, evidently, optimizing for maximum consumption of |
| 39 |
resources with minimal standardization. |
Archives