Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 07/23/19 09:02, Jaco Kroon wrote: > Hi Michał, > > On 2019/07/23 14:39, Michał Górny wrote: >> On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote: >>> On Tue, 23 Jul 2019 13:38:28 +0200 >>> Gerion Entrup wrote: >>> What about a compromise?: Deliver a (prebuild) manpage as package maintainer by default, but keep a use flag "man-build" (or whatever) that builds the man page for everyone (also the maintainer herself) with use of the crazy extra deps. So a user can do (incomplete) version bumps and gets a manpage and the maintainer gets the prebuild manpage in a defined way. >>> You're missing the part where the maintainer is, by the policy, >>> required to, for every bump: >>> >>> 1. Ensure the generated documentation is extracted from the build >>> 2. Packaged into a tarball somewhere >>> 3. Uploaded to a server that can host that tarball >>> 4. Update the package to use that. >>> >>> Failure to do this will mean you're shipping out-dated documentation to >>> the user. >> I fail to see how this could happen, unless you'd be using terrible >> hacks. > And therein lies the issue. We would. >>> This series of back-flips is just not practical at present, and >>> introduces more steps where mistakes can break the ebuild. >> From this thread, it seems that most devs find it impractical to even >> test their ebuilds. > > No. They've been saying that the overhead of maintaining the above > mentioned terrible hacks is unacceptable. Imagine this: > > In order to build man pages I need to pull in 20 additional packages. > So when I roll new ebuild, I need those 20 ... not an issue for me, so > now I need to build the man pages, and I need to create a tarball with > those. A tarball which won't exist at the time when I initially build, > so it's not available to generate a Manifest. So first I have to avoid > those from SRC_URI completely. Then once I've deployed the pre-built > manpages, I need to re-add it. > > So every time there is an upstream version bump, this needs to be > rechecked and determined whether the manpages also needs to be bumped, > or I need to bump unconditionally. More overhead. > > This is outright annoying. Unless it can be automated properly. And I > believe it might be possible, but it'll involve yet more base complexity > by adding build-time dependencies to build man pages to a separate > depend (or at least flag them with a USE=buildman flag), somehow portage > would need to first sort out the building and deployment of the separate > SRC_URI for man pages before adding to the Manifest. You get where I'm > going I hope. > > Everybody agrees with your base premise: It's ideal to ship (optional) > documentation along with every single package, especially if it doesn't > have to pull in a boatload of dependencies. > As an apparently noncorporeal being, I am curious as to why the opinions of other apparently noncorporeal beings [1] are not valued. Further, I would like to remind you that shipping documentation by default does not necessarily imply forcing workarounds to avoid optional documentation, while the proposal in question explicitly would. [1] https://archives.gentoo.org/gentoo-dev/message/f9503369d19a2efd635eb90ac472a962 > Kind Regards, > Jaco > > >
Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses
On Tue, 2019-07-23 at 13:05 -0700, Zac Medico wrote: > On 7/23/19 8:00 AM, Michał Górny wrote: > > Make repoman report user.eclass as deprecated by GLEP 81. > > > > Signed-off-by: Michał Górny > > --- > > repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > > b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > > index 77ad4f625..361da09b9 100644 > > --- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > > +++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > > @@ -30,6 +30,7 @@ class InheritDeprecated(LineCheck): > > "mono": "mono-env", > > "python": "python-r1 / python-single-r1 / python-any-r1", > > "ruby": "ruby-ng", > > + "user": "GLEP 81", > > "versionator": "eapi7-ver (built-in since EAPI 7)", > > "x-modular": "xorg-2", > > } > > > > Looks good, please merge. Merged, thanks. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses
On 7/23/19 8:00 AM, Michał Górny wrote: > Make repoman report user.eclass as deprecated by GLEP 81. > > Signed-off-by: Michał Górny > --- > repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > index 77ad4f625..361da09b9 100644 > --- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > +++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py > @@ -30,6 +30,7 @@ class InheritDeprecated(LineCheck): > "mono": "mono-env", > "python": "python-r1 / python-single-r1 / python-any-r1", > "ruby": "ruby-ng", > + "user": "GLEP 81", > "versionator": "eapi7-ver (built-in since EAPI 7)", > "x-modular": "xorg-2", > } > Looks good, please merge. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
[2019-07-21 08:36:41-0700] Christopher Head: > On July 20, 2019 1:22:39 PM PDT, "Michał Górny" wrote: > >Yes, I get it. User experience is not important if it would mean > >developers would actually do anything but the bare minimum to get > >from one paycheck to another. The usual Gentoo attitude. > > Is my experience as a user really improved if a package I use is dropped > because its maintainer no longer has time to maintain it because they now > have to spend their N available hours per month building man pages for one > package rather than maintaining two? > Well I guess this is quality versus quantity, which depends if gentoo is tight on some of theses packages missing manpages or not… something which I'm not aware of as a proxy-maint contributor but I can imagine other devs with this issue as well.
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Mon, Jul 22, 2019 at 09:04:07PM -0400, Aaron Bauman wrote: > On Sat, Jul 20, 2019 at 08:50:29PM +0300, Andrew Savchenko wrote: > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > > Hello, > > > > > > The QA team would like to introduce the following policy: > > > > > > """ > > > Packages must not disable installing manpages via USE flags (e.g. > > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > > and building them requires additional dependencies, the maintainer > > > should build them and ship along with the package. > > > """ > > > > > > > > > Explanatory note: > > > > > > This applies to having USE flags that specifically control building > > > manpages. It obviously does not affect: > > > > > > a. USE flags that disable building both a program and its manpage (e.g. > > > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1) > > > is correct), > > > > > > b. use of LINGUAS to control installed manpages. > > > > > > > > > Rationale: > > > > > > Manpages are the basic form of user documentation on Gentoo Linux. Not > > > installing them is harmful to our users. On the other hand, requiring > > > additional dependencies is inconvenient. Therefore, packaging prebuilt > > > manpages (whenever upstream doesn't do that already) is a good > > > compromise that provides user with documentation without additional > > > dependencies. > > > > > > > > > What are your comments? > > > > The basic foundation of Gentoo is freedom of choise for our users. > > If installing man pages means no additional dependencies, than > > proposed rule is ok. However if such dependencies are required it is > > up to users to decide if they wan them or not. > > > > Having USE=man (or USE=doc) for such purposes is fine. Having > > USE=man enabled by default in user profile is also fine. Forcing > > users to install unnecessary dependencies on minimal systems in a > > no go and turns Gentoo into something else. > > > > Best regards, > > Andrew Savchenko > > I am going to divert topics here... "freedom"... like freedom to post on a > mailing list without restriction (e.g. whitelisting) ? > > -- > Cheers, > Aaron All, my response above was reported to COMREL as "Pure troll/provocation off-topic on gentoo-dev" My intent here was to challenge bircoph's apparent contradictions of "freedom" of choice and "freedom" of posting on mailing lists. I apologize for appearing to troll/provoke anyone. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses
Make repoman report user.eclass as deprecated by GLEP 81. Signed-off-by: Michał Górny --- repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 + 1 file changed, 1 insertion(+) diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py index 77ad4f625..361da09b9 100644 --- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py +++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py @@ -30,6 +30,7 @@ class InheritDeprecated(LineCheck): "mono": "mono-env", "python": "python-r1 / python-single-r1 / python-any-r1", "ruby": "ruby-ng", + "user": "GLEP 81", "versionator": "eapi7-ver (built-in since EAPI 7)", "x-modular": "xorg-2", } -- 2.22.0
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Wed, 2019-07-24 at 00:59 +1200, Kent Fredric wrote: > On Tue, 23 Jul 2019 14:39:16 +0200 > Michał Górny wrote: > > > > Failure to do this will mean you're shipping out-dated documentation to > > > the user. > > > > I fail to see how this could happen, unless you'd be using terrible > > hacks. > > What part in my series of steps did you not understand? > > All that has to happen is somebody does the bump, and doesn't notice > the documentation didn't change when they did the bump, when it in > fact, aught to have changed. Manpages always change because the program version changes. You ought to include PV in the distfile name. Then you regenerate them always, and you can't miss it. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
Hi Michał, On 2019/07/23 14:39, Michał Górny wrote: On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote: On Tue, 23 Jul 2019 13:38:28 +0200 Gerion Entrup wrote: What about a compromise?: Deliver a (prebuild) manpage as package maintainer by default, but keep a use flag "man-build" (or whatever) that builds the man page for everyone (also the maintainer herself) with use of the crazy extra deps. So a user can do (incomplete) version bumps and gets a manpage and the maintainer gets the prebuild manpage in a defined way. You're missing the part where the maintainer is, by the policy, required to, for every bump: 1. Ensure the generated documentation is extracted from the build 2. Packaged into a tarball somewhere 3. Uploaded to a server that can host that tarball 4. Update the package to use that. Failure to do this will mean you're shipping out-dated documentation to the user. I fail to see how this could happen, unless you'd be using terrible hacks. And therein lies the issue. We would. This series of back-flips is just not practical at present, and introduces more steps where mistakes can break the ebuild. From this thread, it seems that most devs find it impractical to even test their ebuilds. No. They've been saying that the overhead of maintaining the above mentioned terrible hacks is unacceptable. Imagine this: In order to build man pages I need to pull in 20 additional packages. So when I roll new ebuild, I need those 20 ... not an issue for me, so now I need to build the man pages, and I need to create a tarball with those. A tarball which won't exist at the time when I initially build, so it's not available to generate a Manifest. So first I have to avoid those from SRC_URI completely. Then once I've deployed the pre-built manpages, I need to re-add it. So every time there is an upstream version bump, this needs to be rechecked and determined whether the manpages also needs to be bumped, or I need to bump unconditionally. More overhead. This is outright annoying. Unless it can be automated properly. And I believe it might be possible, but it'll involve yet more base complexity by adding build-time dependencies to build man pages to a separate depend (or at least flag them with a USE=buildman flag), somehow portage would need to first sort out the building and deployment of the separate SRC_URI for man pages before adding to the Manifest. You get where I'm going I hope. Everybody agrees with your base premise: It's ideal to ship (optional) documentation along with every single package, especially if it doesn't have to pull in a boatload of dependencies. Kind Regards, Jaco
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Tue, 23 Jul 2019 14:39:16 +0200 Michał Górny wrote: > > Failure to do this will mean you're shipping out-dated documentation to > > the user. > > I fail to see how this could happen, unless you'd be using terrible > hacks. What part in my series of steps did you not understand? All that has to happen is somebody does the bump, and doesn't notice the documentation didn't change when they did the bump, when it in fact, aught to have changed. And just because _I'm_ capable of scruitinizing painfully everything about upstreams changes and actually running tests when I maintain things, doesn't mean I can actually rely on my fellow devs to do the same. The number of bugs I spot that are "somebody bumped a package, didn't even add the new dependencies that were painfully obvious if you even looked at upstreams changes" is too damn high, to the point my intuition is often "see developer bump package, expect them to do it wrong, look at what they changed, then sigh after predicting correctly" I don't like this, but there's f-all I can actually do about it. You have to plan for developers to cock things up, because they're human, and that's what humans do. pgpFUCDORQcXp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote: > On Tue, 23 Jul 2019 13:38:28 +0200 > Gerion Entrup wrote: > > > What about a compromise?: > > Deliver a (prebuild) manpage as package maintainer by default, but keep > > a use flag "man-build" (or whatever) that builds the man page for everyone > > (also the maintainer herself) with use of the crazy extra deps. So a user > > can > > do (incomplete) version bumps and gets a manpage and the maintainer > > gets the prebuild manpage in a defined way. > > You're missing the part where the maintainer is, by the policy, > required to, for every bump: > > 1. Ensure the generated documentation is extracted from the build > 2. Packaged into a tarball somewhere > 3. Uploaded to a server that can host that tarball > 4. Update the package to use that. > > Failure to do this will mean you're shipping out-dated documentation to > the user. I fail to see how this could happen, unless you'd be using terrible hacks. > This series of back-flips is just not practical at present, and > introduces more steps where mistakes can break the ebuild. From this thread, it seems that most devs find it impractical to even test their ebuilds. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Tue, 23 Jul 2019 13:38:28 +0200 Gerion Entrup wrote: > What about a compromise?: > Deliver a (prebuild) manpage as package maintainer by default, but keep > a use flag "man-build" (or whatever) that builds the man page for everyone > (also the maintainer herself) with use of the crazy extra deps. So a user can > do (incomplete) version bumps and gets a manpage and the maintainer > gets the prebuild manpage in a defined way. You're missing the part where the maintainer is, by the policy, required to, for every bump: 1. Ensure the generated documentation is extracted from the build 2. Packaged into a tarball somewhere 3. Uploaded to a server that can host that tarball 4. Update the package to use that. Failure to do this will mean you're shipping out-dated documentation to the user. This series of back-flips is just not practical at present, and introduces more steps where mistakes can break the ebuild. pgpldORzs4geL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
Am Dienstag, 23. Juli 2019, 04:00:07 CEST schrieb Kent Fredric: > On Mon, 22 Jul 2019 21:08:51 -0400 > Aaron Bauman wrote: > > > 1. I want some documentation > > 2. It doesn't ship from upstream (without crazy extra deps) > > 3. Gentoo guy hooked me up and packaged it pre-built with it > > 4. Thanks! > > The proposal as-stated is: > > 1. Documentation requires even 1 additional dep > 2. Thou may not use a USE flag for this > 3. Thus, if you want to elide the dependency from *any* merge graph, >you must elide it from *all* merge graphs. > 4. Thus, you must locally perform some non-standard hackery that will >be different for every package to produce these, work out where to put >it which is also not standardised, and also prohibit the user from >being able to update these themselves via a revision bump, _AND_ you >will need to put in place non-standard mechanisms to ensure it gets >updated when you update the package, in order for the documentation >not to diverge from the sources. What about a compromise?: Deliver a (prebuild) manpage as package maintainer by default, but keep a use flag "man-build" (or whatever) that builds the man page for everyone (also the maintainer herself) with use of the crazy extra deps. So a user can do (incomplete) version bumps and gets a manpage and the maintainer gets the prebuild manpage in a defined way. > > There's a lot of "U, thats bad" in point 4. > > Hence, counter-proposals are trying to look at a way to achieve points > 2 & 3 in your list, without resorting to barbaric torture and inherent > fragility. > > We understand the /achieve, but the mechanism proposed doesn't suit, as > stated. Regards, Gerion signature.asc Description: This is a digitally signed message part.
