On Mon, 22 Jun 2020 at 04:12, Naheem Zaffar <naheemzaffar@xxxxxxxxx> wrote: > > > > On Mon, 22 Jun 2020, 02:57 clime, <clime@xxxxxxxxxxxxxxxxx> wrote: >> >> On Fri, 19 Jun 2020 at 01:59, Josh Boyer <jwboyer@xxxxxxxxxx> wrote: >> > >> > On Thu, Jun 18, 2020 at 5:51 PM clime <clime@xxxxxxxxxxxxxxxxx> wrote: >> > > >> > > On Thu, 18 Jun 2020 at 15:25, Josh Boyer <jwboyer@xxxxxxxxxx> wrote: >> > > > >> > > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits >> > > > <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: >> > > > > >> > > > > -----BEGIN PGP SIGNED MESSAGE----- >> > > > > Hash: SHA512 >> > > > > >> > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote: >> > >> > <snip> >> > >> > > > > > Hopefully that provides some context and helps FESCo and the wider >> > > > > > community understand where Red Hat is headed with modularity on the >> > > > > > Enterprise side. >> > > > > >> > > > > Sadly no. It helps to understand your plans, however it does not help >> > > > > to understand the reasons behind, whether you can't change UX in the >> > > > > RHEL 9, or you think that technology is good enough for your use-cases >> > > > > or any other reasons. >> > > > >> > > > The base requirement is that the UX remain largely the same. As I >> > > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have >> > > > commonality so that our customers are not forced to learn something >> > > > entirely different to adopt RHEL 9. Improvements in the underlying >> > > > functionality are of course welcome and planned, but we are not going >> > > > to do something like replace modules with a different artifact type, >> > > >> > > Hello Josh, >> > > >> > > you can change the artifact type while keeping interface the same and >> > > it would be a _HUGE_ win because it would make modularity finally >> > > understandable for mere humans and better maintainable. >> > > >> > > Namely, modules should become rpms and therefore obey standard rpm rules. >> > >> > I'm not sure I entirely understand what you mean, but it sounds like >> > you have some interesting ideas. >> > >> > I'm looking forward to seeing what you and the community can build >> > from them, and how they could be brought into RHEL 10+! That kind of >> > collaboration is what makes Fedora great. >> >> I know this probably won't change anything because this was mentioned >> many times (by me at least) and nothing has changed but still... >> >> Currently, modules are essentially yum sub-repos, they are not really >> "modules", instead they are collections of rpms that reinvent rpm-like >> relations (obsoletes, requires, build-requires, etc.). >> >> There is no reason for this wheel-reintervention. Modules (the >> collections) can be simply squashed into an rpm by automation and this >> resulting rpm can go to the modular repo together with other modules. >> >> That way we don't have two types of objects we complex inter-relations >> but only one we well-known behavior. >> >> I wonder if this is clear to everyone but nobody really cares or >> doesn't really want to say it or I don't know. >> >> Is this clear to everyone? I mean either I am stating an obvious stuff >> that nobody really considers worth typing or idk. > > > How would this work when there are optional rpms in the module? > > You do not need to install every rpm in eg the php module (different graphics/database backends) for that module to be useful, but every version of the module will have the rpm as an option which wont work outside a module of multiple rpms. Glad you ask, I wasn't precise... Well, I didn't mean everything always needs to be squashed, instead, it would be an optional step in modulemd processing. For some use-cases (like delicately compiled postgresql server), you can create a single rpm that contains all - postgresql-server, postgresql, postgresql-libs compiled in a specific way, optionally with some postgresql modules pre-included, so it would be let's say time-series optimized postgresql. Here it makes sense to make a single rpm from it - you install that and you are all set up for your use-case. Then there are language stacks where you might want to build things in a specific order - there nothing really needs to be squashed (or certain subset can if it makes sense) but you can still use modularity to easily batch-build certain rpms. If there are runtime optional deps, they can be described by Recommends/Suggests. Basically, once a "module" (things that comes from modulemd) is built, it should be put into normal repos and the "module" boundary should be forgotten (unless it is a single rpm), i.e. "module" is a built-time thing, at install-time we just have standard packages with standard deps. dnf interface could be kept given that we "Stream" rpm property is added. This is still a bit rough what I am saying but hopefully it makes at least a bit of sense... clime > > _______________________________________________ > 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
