Walter Dnes wrote:
> Tom Wijsman wrote
> > 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.
>
> Assume that there are 50 different patches available. I may want/need
> features provided by 1 of those patches. I probably do *NOT* want to
> enable the other 49 patches. This is similar in concept to enabling one
> ~amd64 ebuild, versus globally enabling ~amd64.
Agreed. But I'd still like to have the option of enabling the setting in
the {,n,menu..}config, when it's safe to have available as such.
> Even if I can come up with the list of the 49 patches to exclude, what
> happens when the next developer comes along with patch #51? Does it get
> applied next time I build a kernel (ouch)?
But how will I know about it? Seeing the new flag in USE or the expand in
emerge -pv is okay, but not as simple as having it under Gentoo experimental
as a new option, just like every other new kernel config option. That's when
you review the new kernel in any case; with oldconfig, and subsequent nconfig
or w/e.
When it's reasonable to do so, as the patch is verified not to change anything
if its option is unset.
> IANAD (I Am Not A Developer), but if I did want to apply custom
> patches, I think the right approach would be to somewhere manually
> modify UNIPATCH_LIST. If that approach won't work, maybe a USE_EXPAND
> flag make.conf might be the way to go. E.g. CUSTOM_PATCH="foo bar"
> would resolve to USE="custom_patch_foo custom_patch_bar"
Yeah, but I don't want to keep an eye on all that, and mess around with
package.use or expand settings in make.conf. I'd much rather have most
in menuconfig by default with USE=experimental, and then explicitly
include things like aufs.
Just my pov, but I think it fits more with original intent of the idea.
Regards,
steveL
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
