Thanks all for the input. I've made a specific (quite short) proposal [1] for the common streams and profiles including their names. We'll discuss this tomorrow at the Modularity Team meeting (Tuesday 3 PM GMT #fedora-meeting-3).
[1] https://pagure.io/modularity/issue/128 On Thu, Mar 14, 2019 at 4:39 PM Adam Samalik <asama...@redhat.com> wrote: > > > 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 > -- 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
