Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Tom Wijsman]

On Thu, 4 Jul 2013 06:27:59 +0100
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote:

> Tom Wijsman wrote:
> > "Steven J. Long" wrote:
> > > If it does [affect the build by default] then it should never be
> > > applied, unless the user specifically asks for it, imo, and the
> > > resultant kernel is labelled -exp as you suggest.
> >
> > Yes, we are going to introduce an experimental USE flag for this.
>
> That's for the over-arching set of patches isn't it? Which takes care
> of the labelling.

Yes, we currently have "base" and "extras" tarballs for genpatches; it
is trivial to add a "experimental" tarball to this set, all the
optional experimental patches will be in that tarball. This is also
handy for maintainers of other distros whom use genpatches.

> > > > It's just a matter of embedding each + block in the diff with a
> > > > config check and updating the counts.
> ..
> > > > I can convert the original developer's patch whenever he updates
> > > > it; or on top of that, write a script to generate the original
> > > > patch back.
>
> > > Please, just keep a copy of the original patch as well as the
> > > modified output from the script, somewhere reasonable to you, if
> > > you are doing any editing. Traceability is essential here.
> >
> > But yes, some git branches can easily cover the editing part.
>
> I think a lot of these things are checks that should happen before
> patches are included, and on every upgrade. So we need to separate
> out what the developer/ebuild-maintainer has to do to prepare files/,
> and what needs to happen in the ebuild itself.

Please note that this discussion is regarding genpatches; so, there is
no files/ directory and the ebuild change is very minimal, changing one
or two numbers to indicate the genpatches version to use.

Every time I add a patch to genpatches I compile a test kernel using a
test ebuild; I plan to add these checks to our genpatches scripts, then
I can call the checks script from the ebuild in a QA way.

> > > Unless of course the user specifically requests it. This can be a
> > > simple variable with a list of required patches, or whatever.
> >
> > With USE=-experimental (which will be the default) they are
> > excluded by default, after enabling that the user can exclude
> > patches by setting UNIPATCH_EXCLUDE through the package.env
> > mechanism.
>
> I'd feel happier if certain patches, the troublesome ones discussed,
> had to be explicity enabled, before the configuration options and the
> patch to kernel files took place. Perhaps via UNIPATCH_INCLUDE or
> USE=aufs.

There shouldn't be a problem here unless the user applies a lot of
patches that could introduce a colliding patch; in this case the user
either has to fix the conflicting patch or exclude ours. We can't know
for ourselves which patches will be troublesome in this light; but
well, I feel like this only happens on a very exceptional basis. If an
user keeps this amount of patches, ours are probably not needed.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D