1 |
Hi Michał, |
2 |
|
3 |
On 2019/07/23 14:39, Michał Górny wrote: |
4 |
> On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote: |
5 |
>> On Tue, 23 Jul 2019 13:38:28 +0200 |
6 |
>> Gerion Entrup <gerion.entrup@×××××.de> wrote: |
7 |
>> |
8 |
>>> What about a compromise?: |
9 |
>>> Deliver a (prebuild) manpage as package maintainer by default, but keep |
10 |
>>> a use flag "man-build" (or whatever) that builds the man page for everyone |
11 |
>>> (also the maintainer herself) with use of the crazy extra deps. So a user can |
12 |
>>> do (incomplete) version bumps and gets a manpage and the maintainer |
13 |
>>> gets the prebuild manpage in a defined way. |
14 |
>> You're missing the part where the maintainer is, by the policy, |
15 |
>> required to, for every bump: |
16 |
>> |
17 |
>> 1. Ensure the generated documentation is extracted from the build |
18 |
>> 2. Packaged into a tarball somewhere |
19 |
>> 3. Uploaded to a server that can host that tarball |
20 |
>> 4. Update the package to use that. |
21 |
>> |
22 |
>> Failure to do this will mean you're shipping out-dated documentation to |
23 |
>> the user. |
24 |
> I fail to see how this could happen, unless you'd be using terrible |
25 |
> hacks. |
26 |
And therein lies the issue. We would. |
27 |
>> This series of back-flips is just not practical at present, and |
28 |
>> introduces more steps where mistakes can break the ebuild. |
29 |
> From this thread, it seems that most devs find it impractical to even |
30 |
> test their ebuilds. |
31 |
|
32 |
No. They've been saying that the overhead of maintaining the above |
33 |
mentioned terrible hacks is unacceptable. Imagine this: |
34 |
|
35 |
In order to build man pages I need to pull in 20 additional packages. |
36 |
So when I roll new ebuild, I need those 20 ... not an issue for me, so |
37 |
now I need to build the man pages, and I need to create a tarball with |
38 |
those. A tarball which won't exist at the time when I initially build, |
39 |
so it's not available to generate a Manifest. So first I have to avoid |
40 |
those from SRC_URI completely. Then once I've deployed the pre-built |
41 |
manpages, I need to re-add it. |
42 |
|
43 |
So every time there is an upstream version bump, this needs to be |
44 |
rechecked and determined whether the manpages also needs to be bumped, |
45 |
or I need to bump unconditionally. More overhead. |
46 |
|
47 |
This is outright annoying. Unless it can be automated properly. And I |
48 |
believe it might be possible, but it'll involve yet more base complexity |
49 |
by adding build-time dependencies to build man pages to a separate |
50 |
depend (or at least flag them with a USE=buildman flag), somehow portage |
51 |
would need to first sort out the building and deployment of the separate |
52 |
SRC_URI for man pages before adding to the Manifest. You get where I'm |
53 |
going I hope. |
54 |
|
55 |
Everybody agrees with your base premise: It's ideal to ship (optional) |
56 |
documentation along with every single package, especially if it doesn't |
57 |
have to pull in a boatload of dependencies. |
58 |
|
59 |
Kind Regards, |
60 |
Jaco |