On Wed, 13 Mar 2019, Stephen Gallagher wrote:
On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik <asamalik@xxxxxxxxxx> 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-guidelines/
--
Adam ??amal??k
---------------------------
Senior Software Engineer
Red Hat
_______________________________________________
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
_______________________________________________
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
--
/ 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
