lejeczek via FreeIPA-users wrote:
On 09/11/2021 19:18, Rob Crittenden via FreeIPA-users wrote:
> 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.
CentOS Stream? now with RH is in charge.
We as an upstream, regardless of our employer, don't control the builds
which is the important part.
>
> 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(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
>
> Do not reply to spam on the list, report it:
>
https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure