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