| 1 |
Jauhien Piatlicki: |
| 2 |
|
| 3 |
> In the ideal country of elves. In the real life it can be not possible to build and install software in a given distribution without downstream patches. You can find examples of such live ebuilds in Gentoo tree. |
| 4 |
|
| 5 |
I think it's not appropriate and shouldn't generally be done (with a few |
| 6 |
exceptions). If the live ebuild needs heavy patching to even work, then |
| 7 |
don't commit it to the tree. |
| 8 |
|
| 9 |
> Anyway, summarizing, it is completely impossible to be sure that live ebuild will be buildable for you on a given arch in the next 15 min., even if it was so in the last 15 min. |
| 10 |
|
| 11 |
That goes for almost all ebuild variables. So you either drop the whole |
| 12 |
concept of live ebuilds or you do what is reasonable: |
| 13 |
|
| 14 |
a) provide consistent ebuild information, including keywords |
| 15 |
b) ask upstream about their git workflow, which branches they use, what |
| 16 |
arches they even officially support |
| 17 |
c) only add live ebuilds if the upstream git model is something that can |
| 18 |
be relied upon in one way or another and if you can keep up with the changes |
| 19 |
|
| 20 |
If your live ebuild breaks every 15 minutes, then it shouldn't be in the |
| 21 |
tree. |
| 22 |
|
| 23 |
I actually don't commit live ebuild unless I know that upstream is |
| 24 |
collaborative and I'v contributed to almost all of the projects which I |
| 25 |
package as live ebuilds. |
Archives