Re: [gentoo-dev] Re: What are eblits?

[Kent Fredric <kentfredric@gmail.com>]

On 28 May 2016 at 05:35, rindeal <dev.rindeal@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