On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy <aboko...@redhat.com> wrote:
> On to, 14 maalis 2019, Stephen Gallagher wrote: > >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy <aboko...@redhat.com> > wrote: > >> > >> On to, 14 maalis 2019, Stephen Gallagher wrote: > >> >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <aboko...@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. > >> 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. > > > >Well, I may not have done a great job of explaining the Node.js case, > >but let me try to use a different example: Perl > > > >Perl defines a set of modules (not all of which are shipped with the > >interpreter package) that are expected to be present on any standard > >installation. What do we call that profile? To me, "common" seems > >pretty reasonable. We may also have an "interpreter" or "embedded" > >profile that ships a smaller set of content but that would not be the > >default profile. > In case of a programming language it could probably be called > 'standard-environment' or 'runtime' to underline the fact that it is > what is expected from a compliant environment for that programming > language runtime. > > However, for a client-server software there is little can be gained from > making a 'common' profile. What is common for a MariaDB client and a > MariaDB server? What set of modules is considered 'common' for Apache or > Nginx deployments? If there is a common agreement to what is reasonably > expected by the users of that software, then there is a good reason to > name that one 'common' but not in every case. > > >Yes, some of these same problems can and may be solved with standard > >dependencies and metapackages, but profiles will be a bit > >higher-visibility and offer an opportunity for describing things by > >their use-case. > I think that's an opportunity, indeed, but not a requirement to do it > for every single case. ;) > Ah, we're not proposing to force this profile to be used in every case. But when it is used, we just want the name to be consistent across all modules. The same goes for some common stream names. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Adam Šamalík --------------------------- Senior Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
