| 1 |
On Wed, Jul 03, 2013 at 02:42:56PM +0200, Tom Wijsman wrote |
| 2 |
|
| 3 |
> With USE=-experimental (which will be the default) they are excluded by |
| 4 |
> default, after enabling that the user can exclude patches by setting |
| 5 |
> UNIPATCH_EXCLUDE through the package.env mechanism. |
| 6 |
|
| 7 |
Here's my user, not-a-developer, perspective. I think that there |
| 8 |
should be a mechanism to enable one patch at a time. Here's the |
| 9 |
rationale... |
| 10 |
|
| 11 |
Assume that there are 50 different patches available. I may want/need |
| 12 |
features provided by 1 of those patches. I probably do *NOT* want to |
| 13 |
enable the other 49 patches. This is similar in concept to enabling one |
| 14 |
~amd64 ebuild, versus globally enabling ~amd64. |
| 15 |
|
| 16 |
Even if I can come up with the list of the 49 patches to exclude, what |
| 17 |
happens when the next developer comes along with patch #51? Does it get |
| 18 |
applied next time I build a kernel (ouch)? |
| 19 |
|
| 20 |
IANAD (I Am Not A Developer), but if I did want to apply custom |
| 21 |
patches, I think the right approach would be to somewhere manually |
| 22 |
modify UNIPATCH_LIST. If that approach won't work, maybe a USE_EXPAND |
| 23 |
flag make.conf might be the way to go. E.g. CUSTOM_PATCH="foo bar" |
| 24 |
would resolve to USE="custom_patch_foo custom_patch_bar" |
| 25 |
|
| 26 |
-- |
| 27 |
Walter Dnes <waltdnes@××××××××.org> |
| 28 |
I don't run "desktop environments"; I run useful applications |
Archives