On to, 14 maalis 2019, Stephen Gallagher wrote:
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.
I'd say if there is no obvious fit, it is rather confusing to call that
profile 'default' or 'common'. ;)
It is not common to have common profiles for non-obvious stuff. May be
it shouldn't even be having a profile at all? After all, package names
are accessible through existing querying interfaces (dnf search, etc.)
so there is no need to have a specific profile if it is
not-that-specific.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
