| 1 |
В Чтв, 27/12/2007 в 21:05 +0000, Daniel Drake пишет: |
| 2 |
> As for other options: You could just install the patch to the filesystem |
| 3 |
> and require the user to apply it. Other packages do/did this, e.g. hdaps |
| 4 |
|
| 5 |
Ok. Let's me suggest another way. I'd like to standardize (eclass) the |
| 6 |
place such ebuilds install patches. Together with place, I'd like to add |
| 7 |
information (may be in patch name or inside patch itself) what kernels |
| 8 |
this patch supports. Is this the way to go? |
| 9 |
|
| 10 |
After this I'm sure there will be no problem to have external tool to |
| 11 |
simplify patching. If you do not like it - do not use it. |
| 12 |
|
| 13 |
> But the only real solution is this: get the patch merged upstream, or |
| 14 |
> equivalent functionality offered in the mainline kernel. Everything else |
| 15 |
> is working against the flow of the kernel. |
| 16 |
|
| 17 |
Eh. I see your intentions. But IMQ will never get upstream while me and |
| 18 |
many other people are using it and AFAIK currently there is not |
| 19 |
substitution for it (IFB is different). patch-o-matic patches are really |
| 20 |
slow in moving to official tree, while I have to use it's functionality. |
| 21 |
There will be always such patches. |
| 22 |
|
| 23 |
-- |
| 24 |
Peter. |
Archives