| 1 |
On Mon, 30 Jan 2017 14:04:06 -0600 |
| 2 |
William Hubbs <williamh@g.o> wrote: |
| 3 |
|
| 4 |
> As I said on the bug, the downside is the addition of py3 and ninja as |
| 5 |
> build time dependencies, but I think the upside (a build system where |
| 6 |
> we don't have to worry about parallel make issues or portability) |
| 7 |
> outweighs that. |
| 8 |
|
| 9 |
On principle I would discourage this course of action. |
| 10 |
|
| 11 |
Critical infrastructure should be built on proven and established technology |
| 12 |
that has practically become boring to the point of almost-stagnation. |
| 13 |
|
| 14 |
Building things atop of newer technology ends up being like building upon |
| 15 |
shifting sands. |
| 16 |
|
| 17 |
And all this is doubly important if you're ever needing to bootstrap. |
| 18 |
|
| 19 |
ie: It might be justifiable to build openrc on top of meson on an established |
| 20 |
system which already has a working openrc, but building openrc on meson |
| 21 |
when you're installing your first Gentoo install is going to be much more painful |
| 22 |
than it should be. |
| 23 |
|
| 24 |
And we should be keeping the @system essentials set required for new installations |
| 25 |
to be as minimal as possible without losing functionality. |
| 26 |
|
| 27 |
And here, I think the objectives of being parallel-make friendly are small |
| 28 |
in compare with the overhead for ensuring the dependencies are present and working |
| 29 |
and usable on a clean install. |
| 30 |
|
| 31 |
But a package that has only been in tree a measly 7 months seems far, far |
| 32 |
too premature to switch to being a mandatory part of the critical path. |
Archives