DevHeads.net

Bringing order to the confusing module stream and profile names

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]
<a href="https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/" title="https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/">https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-gu...</a>

Comments

Re: Bringing order to the confusing module stream a

By Stephen Gallagher at 03/13/2019 - 16:00

On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik < ... at redhat dot com> wrote:
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.

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".

Re: Bringing order to the confusing module stream a

By Alexander Bokovoy at 03/14/2019 - 01:57

On Wed, 13 Mar 2019, Stephen Gallagher wrote:
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.

Re: Bringing order to the confusing module stream a

By Stephen Gallagher at 03/14/2019 - 09:33

On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy < ... at redhat dot com> wrote:
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.

Re: Bringing order to the confusing module stream a

By Alexander Bokovoy at 03/14/2019 - 09:40

On to, 14 maalis 2019, Stephen Gallagher wrote:
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.

Re: Bringing order to the confusing module stream a

By Stephen Gallagher at 03/14/2019 - 10:09

On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy < ... at redhat dot com> wrote:
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.

Re: Bringing order to the confusing module stream a

By Alexander Bokovoy at 03/14/2019 - 11:34

On to, 14 maalis 2019, Stephen Gallagher wrote:
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.

Re: Bringing order to the confusing module stream a

By Adam Samalik at 03/14/2019 - 11:39

On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy < ... at redhat dot com>
wrote:

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.

Re: Bringing order to the confusing module stream a

By Adam Samalik at 03/25/2019 - 07:36

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] <a href="https://pagure.io/modularity/issue/128" title="https://pagure.io/modularity/issue/128">https://pagure.io/modularity/issue/128</a>