On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <abokovoy(a)redhat.com> 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.