Harry G. Coin via FreeIPA-users wrote: > 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.
Yes, we have a lot of dependencies, and dependencies of dependencies. Some of the major packages work with us and test their release candidates against IPA before releasing. Others not so much. We have automation that tends to find most of this in the wild on Fedora. We have no control over CentOS or the other rebuilds and have some limited influence in other distributions. IPA is a release blocker in Fedora so if the automation isn't passing during a release it can be blocked, but there is no package resolver I know of that detects whether an upgrade in a package will break IPA. I'm not sure there is the computing capacity to test for that. I have no memory of a database corruption issue on upgrade in all my time in IPA, either NSS or 389-ds. rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
