Regarding to a few of the questions about why modularity was created in the first place (paraphrased), I can offer the following background. Note, I was not on the team at the very beginning but have been very involved for the last ~2 years.
Do not consider the following to be formal answers, guidance, or laws of nature. I'm only trying to help share some perspective.
From the RHEL Product Management (PM) side, we observed the following customer+market problems. Note this is not a perfect list but a rough, paraphrased, quick brain dump:
- Customers think we had too many repos. It is hard to find what they need.
- optional, supplementary, extras, software collections, and more...
- Customers need more options that are fully supported to meet their production workload requirements.
- 1. "I need as little change as possible. I will stick with the version of DB provided with X.0 release for the next 10 years."
- 2. "I need newer versions of xyz to benefit from some features."
- 3. A few states in between 1 & 2.
- "Software Collections are helpful and provide us more choices, but the user experience is awkward and most of the time we only install 1 version at a time, with the exception of a few programming language environments (multiple python, gcc, and so forth)." And it's a different repo and a non-native software management workflow.
- RH need the distinction to provide realistic life cycles that matched the true upstream life cycle. 5 year life cycles of DB's are a good example, as well as the python 2 reaching its end of life. Application Stream modules help with defining this, as well as enabling customers to block access to versions that have reached the end of their life cycle.
Thus, RHEL PM asked for a method so solve these problems above. PM objectives ideally should not dictate the technical implementation but rather focus on addressing the customer/market problems, user experience, supportability, and things like that. My understanding was that package-name-versioning could have been acceptable to PM, but there were a number of support and engineering challenges which led to the modularity design.
That said, some of the internal guidance was that:
- Only select modules are parallel installable, primarily programming languages such as python.
- while modularity could help with some traditional repository challenges, it does not solve all, nor does it make RPM dependency problems go away. Therefore only select things in Appstream should be modularized, usually when collections of rpms serve a common use case, such as databases or Identity Management.
- The RHEL distribution ensures a sane state of compatibility to ensure a good user experience. So the analogy of conflicts with many different repos does not magically go away.
- Disciplined distribution content management policies and compatibility are still required as if they were different repos.
- Default stream versions defined so that if a user wants a simple RHEL 7 like experience, they have it. They are not forced to use modularity unless they want to or their workload dictates different modules.
- Changing streams is a manual process, at least until modularity matures. If a customer chooses a stream for their workload, we cannot break that customer's workload. Though shalt do no harm. Therefore auto-stream switching is off-limits in RHEL. At least for now until we further understand customer demand and the risk impact as Appstream grows to include more modules.
That's all I can think of right now and I might have missed some things. Again, it does NOT answer many of the questions in this thread and we know we have future work to do. I would be happy to consult with, but not dictate to, Fedora members on defining their own policy guidelines if desired.
Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
On Mon, Jun 17, 2019 at 2:52 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, Jun 17, 2019 at 2:29 PM Colin Walters <walters@xxxxxxxxxx> wrote:
>
> On Mon, Jun 17, 2019, at 4:47 AM, Michael Schroeder wrote:
> > On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > > I would actually really like to see rpm's multiversioning capabilities
> > > extended to support this.
> >
> > I'd actually prefer to drop the multiversion mode for the kernel and
> > instead add the version to the kernel package name.
>
> FWIW in rpm-ostree we go to some lengths to explicitly undo the libdnf default of multiple versions for the kernel, because the ostree side of things effectively multi-versions all of userspace as well. We're always creating a new root, so there's no concern about removing modules from the running kernel (any more than there is a similar concern for userspace components). An ostree deployment includes a (kernel+initramfs,userspace) as a pair; two deployments can happen to share a kernel, or not. A bit more info in
> https://github.com/projectatomic/rpm-ostree/pull/1346
RPM-OSTree is functionally irrelevant in this discussion, since it has
its own behavior patterns and eschews compatibility with the greater
ecosystem anyway. It doesn't even support modules, so this whole
discussion doesn't even matter for systems built on RPM-OSTree.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
