[modularity] Bringing order to the confusing module stream and profile names

[Adam Samalik]

There are module streams named 'latest', 'stable', or 'master',
but it's
not quite clear what exactly those mean. Some modules even have the
'master' and the 'latest' streams at the same time which feels quite
confusing.

In a similar manner, there are various unclear profile names, too.
Especially the one called 'default', not always being the default profile.
I see a module having three profiles called 'default', 'client' and
'server', and the 'server' is the default. What does the one named
'default' represent, then?

We need to bring some order into this.

The Modularity team has published naming guidelines [1] covering some of
the cases, but we've recognized it doesn't cover all the cases and that it
needs an overall refresh.

So let's start with identifying different cases that should have a unified
name — let's say by Monday 18 March. And then, when we see all of them
listed, we can name them in a clear and consistent manner.

I've started a list below, let's add to it and discuss. Some of them might
get merged into one, others might get split into more.

== Streams

A) Nightly developer builds
B) The latest stable release, automatically switching to the next latest
stable when available
C) Stable rolling release for projects without a clear versioning scheme
D) Devel/unstable rolling release for projects without a clear versioning
scheme

I'm leaving out the version-specific streams such as X or X.Y or even
X.Y.Z, as well as the 'calver' ones as they work fine and we're not
changing these.

== Profiles

a) The most common installation if there is one
b) The client-side installation
c) The server-side installation
d) Installation providing a development environment such as -devel packages


Any other common cases for streams or profiles that need a unified name?
Let's try to find them all by Monday 18 March.

Thanks,
Adam

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-gui...
-- 

Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat

[Stephen Gallagher]

On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik <asamalik(a)redhat.com&gt; wrote:
>  There are module streams named 'latest', 'stable', or 'master',
> but it's not quite clear what exactly those mean. Some modules even have the
> 'master' and the 'latest' streams at the same time which feels quite
> confusing.
>
>  In a similar manner, there are various unclear profile names, too. Especially the one
> called 'default', not always being the default profile. I see a module having
> three profiles called 'default', 'client' and 'server', and the
> 'server' is the default. What does the one named 'default' represent,
> then?
>
>  We need to bring some order into this.
>
>  The Modularity team has published naming guidelines [1] covering some of the cases, but
> we've recognized it doesn't cover all the cases and that it needs an overall
> refresh.
>
>  So let's start with identifying different cases that should have a unified name —
> let's say by Monday 18 March. And then, when we see all of them listed, we can name
> them in a clear and consistent manner.
>
>  I've started a list below, let's add to it and discuss. Some of them might get
> merged into one, others might get split into more.
>
>  == Streams
>
>  A) Nightly developer builds
>  B) The latest stable release, automatically switching to the next latest stable when
> available
>  C) Stable rolling release for projects without a clear versioning scheme
>  D) Devel/unstable rolling release for projects without a clear versioning scheme
>
>  I'm leaving out the version-specific streams such as X or X.Y or even X.Y.Z, as well
> as the 'calver' ones as they work fine and we're not changing these.
>
>  == Profiles 
Something that we really need to make clear: Profiles are essentially
installation groups that are meant to be described by their use-case.
When users look at the available profiles, the ideal case is for the
name to indicate to them what problem it will solve.

I like to use Samba as an example here because, being a large and
complicated project, it would have meaningful profiles for a variety
of use-cases (the below are just examples):
* mount_support: Packages needed to support mounting SMB shares as local paths
* smb_client: Client tools like smbclient
* file_server: Packages needed to share local files to other systems
* domain_controller: Packages needed to run a Windows Domain Controller
* devel: Packages needed to build software that depends on Samba libraries.

>  a) The most common installation if there is one 
I think we ought to rephrase this. Generally speaking, since we can
have multiple profiles be the default (e.g. 'server' and 'client'), it
makes sense in most cases to  just separate the profiles by their
use-case. What we *do* need to do is agree on a name for those rare
cases where there's no obvious use-case name to describe them. For
example, with Node.js, you wouldn't really want to name the `nodejs`
package a "server". You *might* call it an "interpreter", but
that's
limiting. So having a generic fallback name makes sense.

To date, we've used the profile name "default", but that was a
holdover from early in development when we thought that we'd have DNF
implement a fallback such that if the module had a profile with the
special-case name "default", we would use that if the user didn't
specify one at the command-line. DNF doesn't actually implement this
and we now have the much more flexible modulemd-defaults approach, so
the name "default" is both vestigial and confusing.

RHEL 8 Beta shipped with a number of modules using the profile name
"common" to satisfy this case, mostly to avoid the confusion inherent
in naming a profile "default".

> b) The client-side installation
> c) The server-side installation
> d) Installation providing a development environment such as -devel packages
>
>
> Any other common cases for streams or profiles that need a unified name? Let's
try to find them all by Monday 18 March.
>
> Thanks,
> Adam
>
> [1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-gui...
> --
>
> Adam Šamalík
> ---------------------------
> Senior Software Engineer
> Red Hat
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Alexander Bokovoy]

On Wed, 13 Mar 2019, Stephen Gallagher wrote:
> On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik
> <asamalik(a)redhat.com&gt; wrote:
> >
> > There are module streams named 'latest', 'stable', or
> 'master', but
> > it's not quite clear what exactly those mean. Some modules even have
> > the 'master' and the 'latest' streams at the same time which feels
> > quite confusing.
> >
> > In a similar manner, there are various unclear profile names, too.
> > Especially the one called 'default', not always being the default
> > profile. I see a module having three profiles called 'default',
> > 'client' and 'server', and the 'server' is the default. What
> does the
> > one named 'default' represent, then?
> >
> > We need to bring some order into this.
> >
> > The Modularity team has published naming guidelines [1] covering some
> > of the cases, but we've recognized it doesn't cover all the cases and
> > that it needs an overall refresh.
> >
> > So let's start with identifying different cases that should have a
> > unified name ??? let's say by Monday 18 March. And then, when we see
> > all of them listed, we can name them in a clear and consistent
> > manner.
> >
> > I've started a list below, let's add to it and discuss. Some of them
> > might get merged into one, others might get split into more.
> >
> > == Streams
> >
> > A) Nightly developer builds
> > B) The latest stable release, automatically switching to the next latest stable when
> available
> > C) Stable rolling release for projects without a clear versioning scheme
> > D) Devel/unstable rolling release for projects without a clear versioning scheme
> >
> > I'm leaving out the version-specific streams such as X or X.Y or even X.Y.Z, as
> well as the 'calver' ones as they work fine and we're not changing these.
> >
> > == Profiles
>
> Something that we really need to make clear: Profiles are essentially
> installation groups that are meant to be described by their use-case.
> When users look at the available profiles, the ideal case is for the
> name to indicate to them what problem it will solve.
>
> I like to use Samba as an example here because, being a large and
> complicated project, it would have meaningful profiles for a variety
> of use-cases (the below are just examples):
> * mount_support: Packages needed to support mounting SMB shares as local paths
> * smb_client: Client tools like smbclient
> * file_server: Packages needed to share local files to other systems
> * domain_controller: Packages needed to run a Windows Domain Controller
> * devel: Packages needed to build software that depends on Samba libraries. 
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.


> >
> > a) The most common installation if there is one
>
> I think we ought to rephrase this. Generally speaking, since we can
> have multiple profiles be the default (e.g. 'server' and 'client'), it
> makes sense in most cases to  just separate the profiles by their
> use-case. What we *do* need to do is agree on a name for those rare
> cases where there's no obvious use-case name to describe them. For
> example, with Node.js, you wouldn't really want to name the `nodejs`
> package a "server". You *might* call it an "interpreter", but
> that's
> limiting. So having a generic fallback name makes sense.
>
> To date, we've used the profile name "default", but that was a
> holdover from early in development when we thought that we'd have DNF
> implement a fallback such that if the module had a profile with the
> special-case name "default", we would use that if the user didn't
> specify one at the command-line. DNF doesn't actually implement this
> and we now have the much more flexible modulemd-defaults approach, so
> the name "default" is both vestigial and confusing.
>
> RHEL 8 Beta shipped with a number of modules using the profile name
> "common" to satisfy this case, mostly to avoid the confusion inherent
> in naming a profile "default".
>
> > b) The client-side installation
> > c) The server-side installation
> > d) Installation providing a development environment such as -devel packages
> >
> >
> > Any other common cases for streams or profiles that need a unified name? Let's
> try to find them all by Monday 18 March.
> >
> > Thanks,
> > Adam
> >
> > [1]
> https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-gui...
> > --
> >
> > Adam ??amal??k
> > ---------------------------
> > Senior Software Engineer
> > Red Hat
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Stephen Gallagher]

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

[Alexander Bokovoy]

On to, 14 maalis 2019, Stephen Gallagher wrote:
> On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; 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

[Stephen Gallagher]

On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  On to, 14 maalis 2019, Stephen Gallagher wrote:
>  >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <abokovoy(a)redhat.com&gt; 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.

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.

[Alexander Bokovoy]

On to, 14 maalis 2019, Stephen Gallagher wrote:
> On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> >
> > On to, 14 maalis 2019, Stephen Gallagher wrote:
> > >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
> 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

[Adam Samalik]

On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
wrote:

>  On to, 14 maalis 2019, Stephen Gallagher wrote:
>  >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
>  wrote:
>  >>
>  >> On to, 14 maalis 2019, Stephen Gallagher wrote:
>  >> >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy
> <abokovoy(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat

[Adam Samalik]

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 <asamalik(a)redhat.com&gt; wrote:

>  On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
>  wrote:
>
> > On to, 14 maalis 2019, Stephen Gallagher wrote:
> > >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy <abokovoy(a)redhat.com&gt;
> > wrote:
> > >>
> > >> On to, 14 maalis 2019, Stephen Gallagher wrote:
> > >> >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy <
> > abokovoy(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
>
>
>  --
>
>  Adam Šamalík
>  ---------------------------
>  Senior Software Engineer
>  Red Hat
>  

-- 

Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat