On to, 14 maalis 2019, Stephen Gallagher wrote:
On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote:
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.
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. ;)
--
/ 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
