Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
Date: Wed, 03 Jul 2013 12:46:11
Message-Id: 20130703144256.68e4aef8@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Re: Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. by "Steven J. Long"
1 On Wed, 3 Jul 2013 11:45:55 +0100
2 "Steven J. Long" <slong@××××××××××××××××××.uk> wrote:
3
4 > Tom Wijsman wrote:
5 > > > > Earlier I mentioned "3) The patch should not affect the build by
6 > > > > default."; if it does, we have to adjust it to not do that,
7 > > > > this is something that can be easily scripted.
8 >
9 > If it does then it should never be applied, unless the user
10 > specifically asks for it, imo, and the resultant kernel is labelled
11 > -exp as you suggest.
12
13 Yes, we are going to introduce an experimental USE flag for this.
14
15 > > It's just a matter of
16 > > > > embedding each + block in the diff with a config check and
17 > > > > updating the counts.
18 > > >
19 > > > Wonderful, now you are maintaining a patch that looks nothing
20 > > > like the one created by the original developers, nor tested by
21 > > > anyone else other than gentoo developers.
22 > >
23 > > I can convert the original developer's patch whenever he updates
24 > > it; or on top of that, write a script to generate the original
25 > > patch back.
26 >
27 > Please, just keep a copy of the original patch as well as the modified
28 > output from the script, somewhere reasonable to you, if you are doing
29 > any editing. Traceability is essential here.
30
31 The need to keep duplicates around is a broken design; if you would
32 need to do this, there is something worse going on. But yes, some git
33 branches can easily cover the editing part.
34
35 > Personally I think it ill-advised, and would prefer simply that the
36 > patch were not applied if the above process in your testing prior to
37 > usage, showed that it would affect other parts of the build
38 > inappropriately, even when configured off. Or it's known to do so,
39 > like aufs.
40
41 Maybe, we can hear whether the patch authors want to do something about
42 this, so we don't have to convert patches like this; maybe most of them
43 are willing to do this without a problem. Though, there are going to be
44 parts that they want to unconditionally apply, which is why we will
45 need to wrap those parts with a check.
46
47 > Unless of course the user specifically requests it. This can be a
48 > simple variable with a list of required patches, or whatever.
49
50 With USE=-experimental (which will be the default) they are excluded by
51 default, after enabling that the user can exclude patches by setting
52 UNIPATCH_EXCLUDE through the package.env mechanism.
53
54 --
55 With kind regards,
56
57 Tom Wijsman (TomWij)
58 Gentoo Developer
59
60 E-mail address : TomWij@g.o
61 GPG Public Key : 6D34E57D
62 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies