On Mon, 22 Jun 2020 at 08:14, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > On Mon, Jun 22, 2020 at 04:55:10AM +0200, clime wrote: > > >> > > 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. > > I agree with this general idea, even if not with the exact implementation > (comments below). In the past this was stated as "divorcing the build ordering > mechanism from the rpm delivery mechanism". The fact that we have two layers > of dependencies make Modularity conceptually hard and destroy the interaction > with the dependency solver. Also, if we disconnect the build and delivery > mechanisms, we can iterate and improve both separately.
Indeed, I agree build and delivery mechanisms should be treated independently. Things would finally get a clear shape. > > > >> 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. > > So... if it's only optional, that means that the general case where > squashing is not done needs to be solved anyway. And once you have > solved the general case, what would the point of squashing be? > Thus, I don't find squashing useful. > > > 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. > > Yep. > > The unanswered question is what mechanism would be used make sure that > the rpms from the "module" are all installed. One option would be to > somehow mangle rpm names, another option would be to add some kind of > Provides/Requires, etc. But *some* mechanism is needed, because without > that dnf would often pick other rpms. > > In Modularity the solution is that the rpms from the module shadow > rpms with the same name from outside. That's probably the single > feature of Modularity that causes the most problems. > > > 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... > > Zbyszek > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
