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). > > 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?
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 > -- Fabian Groffen Gentoo on a different level
signature.asc
Description: PGP signature
