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