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
>> > 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
>> 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.
>> That way we don't have two types of objects we complex
>> 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.
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
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
added. This is still a bit rough what I am saying but hopefully it
makes at least a bit of sense...