| 1 |
On 28 May 2016 at 05:35, rindeal <dev.rindeal@×××××.com> wrote: |
| 2 |
> This whole concept, however, raises the question (as suggested by |
| 3 |
> Ciaran McCreesh and Duncan) if it's allowed to split ebuilds to |
| 4 |
> several bash scripts and what have QA and dev-manual got to say in |
| 5 |
> this regard? |
| 6 |
|
| 7 |
|
| 8 |
Personally I'd say the biggest risk from a QA perspective of this |
| 9 |
approach is important changes shared amongst ebuilds might require the |
| 10 |
change be done in an eblit, but the change itself may require all |
| 11 |
existing users of the ebuilds perform a reinstall. |
| 12 |
|
| 13 |
This is already a problem with eclasses where eclass changes might |
| 14 |
necessitate all dependent ebuilds being rebuilt in some way, but we |
| 15 |
fence that out of existence with QA policies against such changes. ( A |
| 16 |
popular fencing mechanism is via EAPI conditionals and ENV vars which |
| 17 |
require the end ebuild to explicitly opt in to the change for it to |
| 18 |
take affect, thus, causing the propagation to occur explicitly ) |
| 19 |
|
| 20 |
Under eblits, the same sorts of logic can occur, but the temptation to |
| 21 |
change the eblit and not the ebuild is substantially greater. |
| 22 |
|
| 23 |
But the necessity to bump the ebuild to cascade the rebuild is still |
| 24 |
there ( and greater ) |
| 25 |
|
| 26 |
Which means in practice, eblits can make cascades harder, and |
| 27 |
encourage devs not to perform ... |
| 28 |
|
| 29 |
Which is a rather bad combination of pressures. |
| 30 |
|
| 31 |
Hence, eblits as they currently exist are experts-only and a big |
| 32 |
danger ground for QA violations *to occur within*, even under the |
| 33 |
presumption that they're not inherently a QA violation in themselves. |
| 34 |
|
| 35 |
-- |
| 36 |
Kent |
| 37 |
|
| 38 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives