8 a.m.
I think freeipa represents something of a research opportunity.
Among all the 'functional subsystem packages' out there, freeipa is the
'tallest pyramid with the widest base' I'm aware of. By that I mean it
has the largest number of dependencies which themselves are also
subsystems (over against libraries with little more than libc/kernel
dependencies); and that in order to be considered 'up and useful' all of
the subsystems contribute to the necessary 'running properly'
condition. In fact many of the subsystems freeipa relies upon are
themselves reliant on what you might call 'functional subsystems'.
You might argue a 'distro' or a GUI environment would be better, but
that's more like a collection of shorter pyramids where the 'breakage'
of one doesn't materially impact the others.
A hypothesis worth getting actual metrics on would be how often it would
appear 'freeipa breaks upon install' and 'freeipa breaks upon upgrade'
when installed via a stream-style release, over against 'vm' or 'docker'
releases, and that over against 'lts/rhel/centos' vs fedora.
Over the coming decades, a question needs resolving-- how high a 'brick
wall' is possible and sustainable (where each 'brick' is a dependency)
and what can be done to make 'higher walls' more reliable? Because each
subsystem represents thousands of hours of focused labor, and that
packaged and made available to other developers faced with either
re-creating the function or using the subsystem.
Presently we're faced with the smallest changes in a dependency
corrupting a database upon 'upgrade', or some seeming trifle breaking
the ui, etc.
I suppose it would lead to a 'so, then, with that, now what?' question
-- and that would be really interesting as well.
So, there's a Monday morning idea.
Harry Coin