On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: > This split is very artificial. In practice, at least for first four use > cases you actually want first three to be available always because they > are used by various parts of the code (especially by the fourth one). > > It is probably better to show this with FreeIPA. In RHEL8 beta we did > several profiles: > - client, only providing a bare minimum of FreeIPA client packages > (freeipa-client, essentially) > - server, only providing basic FreeIPA master without DNS and trust to > AD support > - dns, which is server profile + freeipa-server-dns package which pulls > in bind and bind-dyndb-ldap > - adtrust, which is server + freeipa-server-trust-ad package which > pulls in Samba and other packages needed to configure IPA master to > trust Active Directory configuration, including FreeIPA plugins to > allow management of FreeIPA by users from Active Directory > > If you are only interested in client-side operations, you'd install > client profile. If you need full support, you'd install dns+adtrust > which will bring in all individual packages you shouldn't worry about. > > The difference between a profile and a normal package dependency is that > in profile I can encode use-case specific knowledge for a set of > dependencies which span packages that could cater to multiple use cases. > Sure, it was a contrived example. I was mostly trying to demonstrate that use-case based names for profiles must always be the preferred approach (which FreeIPA did perfectly). The open question in this thread has to do with "what do we call it when there's no obvious fit?". We've been using "default" up to this point, but that's a terribly confusing name. We've suggested "common" as an alternative that doesn't carry the implication that it must be (or automatically is) the default installed stream. But I don't want to start that particular bikeshed; I wanted to explain the scope of the problem and see if we had agreement on that being one of the concepts that deserves a unified name. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
