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

[Steven J. Long]

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.
 
> > > 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.
>
> The need to keep duplicates around is a broken design; if you would
> need to do this, there is something worse going on.

There is indeed: there's major changes to other parts of the kernel tree,
even when the patch's configuration options are set to off, as they are
by default (or must be in the Gentoo experimental config patch.) That's
the reason they were not accepted, as has been discussed earlier in the
thread.

> 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.

> > Personally I think it ill-advised, and would prefer simply that the
> > patch were not applied if the above process in your testing prior to
> > usage, showed that it would affect other parts of the build
> > inappropriately, even when configured off. Or it's known to do so,
> > like aufs.
>
> Maybe, we can hear whether the patch authors want to do something about
> this, so we don't have to convert patches like this; maybe most of them
> are willing to do this without a problem.

The conversation is definitely worth having. Especially if Gentoo runs
automated tests on the patchsets to verify previously "safe" patches
are still safe to apply unconditionally, ie that all changes are #ifdef
or #if guarded.

> Though, there are going to be
> parts that they want to unconditionally apply, which is why we will
> need to wrap those parts with a check.

Indeed; upstream patch authors are not going to suddenly change, especially
with the known-troublesome cases, while there is still the need to make
the patches available to users who would otherwise be applying them
without Gentoo -exp labelling.

> > 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.

Regards,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)