We really don't want conditional patches, but I from my experience
reality is that sometimes you have to. Therefore this should remain possible. I have no problems with highly discouraging conditional
patching.
About your other points, I think they are kind of debatable. Gentoo
wants to be close to upstream, but with your set of rules, one can't
e.g. add hpn patches to ssh, which would be really silly, as the point
of Gentoo is that since you build from source, you can actually apply
such patches, conditionally if they don't have a means to be disabled.
In other words, I think the gist of your points is to be in an ideal
world, but unfortunately reality is far from it. That said, repeating myself, nothing wrong with discouraging quick 'n' dirty, for as long as
it remains a big fat warning and advice.
Hi!
I've been working on a new section in the devmanual regarding conditional patching. In a PR [0] Sam suggested adding a section to clarify that conditional
patching should be avoided, because it can quickly become a maintenance and testing burden.
The devmanual PR is here: [1]
Ulrich points out that conditional patching is actually suggested elsewhere, and
that actively discouraging conditional patching is a policy change, which should
be brought up on this list. So this is what I'm doing now. He also pointed out a
comment in eutils.eclass re [2] (the comment now lives in epatch.eclass).
The overall policy (proposal, I guess) is something like:
* Patches should be written such that they affect behaviour correctly based on
e.g. build time definitions or config options, rather than USE flags
directly.
* They should be applied unconditionally, so that, for version bumps and other
development happening with a package, any failure to apply the patch will be
caught by the developer.
* Patching is ideally only done to make the package in question build properly,
and should not be done to modify the runtime behaviour of the package. (This
is what USE flags and configuration options of the package are for.)
Sam made a specific point re musl: "for e.g. musl patches, we want a portable fix, not a hack which is only applied for musl"
Feedback on this very welcome. I'm grappling a bit with the exact wording to go
for, so input on that is also appreciated.
I think my question to this list is: Should it be policy that conditional patching is to be avoided?
[0]: https://github.com/gentoo/gentoo/pull/24709#discussion_r832361402
[1]: https://github.com/gentoo/devmanual/pull/281
[2]: https://gitweb.gentoo.org/archive/repo/gentoo-2.git/tree/eclass/eutils.eclass?id=50e8beda904760c773e5c67fdfe8242255e13495#n175
On 29 Mar 2022, at 04:43, Sam James <sam@gentoo.org> wrote:
On 28 Mar 2022, at 12:05, Thomas Bracht Laumann Jespersen <t@laumann.xyz> wrote:
Hi!
I've been working on a new section in the devmanual regarding conditional
patching. In a PR [0] Sam suggested adding a section to clarify that conditional
patching should be avoided, because it can quickly become a maintenance and >> testing burden.
On 28 Mar 2022, at 12:13, Fabian Groffen <grobian@gentoo.org> wrote:
Hi,
On 28-03-2022 13:05:03 +0200, Thomas Bracht Laumann Jespersen wrote:
Hi!
I've been working on a new section in the devmanual regarding conditional
patching. In a PR [0] Sam suggested adding a section to clarify that conditional
patching should be avoided, because it can quickly become a maintenance and >> testing burden.
The devmanual PR is here: [1]
Ulrich points out that conditional patching is actually suggested elsewhere, and
that actively discouraging conditional patching is a policy change, which should
be brought up on this list. So this is what I'm doing now. He also pointed out a
comment in eutils.eclass re [2] (the comment now lives in epatch.eclass).
[snip]
I think my question to this list is: Should it be policy that conditional
patching is to be avoided?
We really don't want conditional patches, but I from my experience
reality is that sometimes you have to. Therefore this should remain
possible. I have no problems with highly discouraging conditional
patching.
About your other points, I think they are kind of debatable. Gentoo
wants to be close to upstream, but with your set of rules, one can't
e.g. add hpn patches to ssh, which would be really silly, as the point
of Gentoo is that since you build from source, you can actually apply
such patches, conditionally if they don't have a means to be disabled.
In other words, I think the gist of your points is to be in an ideal
world, but unfortunately reality is far from it. That said, repeating
myself, nothing wrong with discouraging quick 'n' dirty, for as long as
it remains a big fat warning and advice.
My €0.02
Fabian
[0]: https://github.com/gentoo/gentoo/pull/24709#discussion_r832361402
[1]: https://github.com/gentoo/devmanual/pull/281
[2]: https://gitweb.gentoo.org/archive/repo/gentoo-2.git/tree/eclass/eutils.eclass?id=50e8beda904760c773e5c67fdfe8242255e13495#n175
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 97:50:01 |
Calls: | 6,699 |
Calls today: | 4 |
Files: | 12,232 |
Messages: | 5,349,458 |