On Tue, Mar 5, 2019 at 11:01 AM stan <upaitag(a)zoho.com> wrote:
On Tue, 5 Mar 2019 09:08:19 +0100
Adam Samalik <asamalik(a)redhat.com> wrote:
> On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth <mike(a)cchtml.com>
> > Why should I care? Please, win me over. (I'm being serious.)
> I think you should care if:
> a) You need to maintain multiple versions of the same app/runtime/set
> of tools tools in Fedora (or an alternative to something that already
> exists), or
> b) You only want to maintain one source branch per package for all
> Fedora releases, or
> c) You could benefit from having a build recipe in case you maintain
> app/runtime/set of tools tools represented by multiple packages that
> need to be built in the right order
> But if any of the above is something that you need/want to do, then
> Modularity won't help you nor hurt you in any way.
> > I view the current RPM system as reliable, standard, and
> > well-documented. It's
> > served me and the people I know that use it well for decades. I view
> > Modularity as
> > an answer to a question no one asked. It presents new problems that
> > never existed
> > and has been somewhat silently taking over RPM-land with very little
> > community
> > involvement.
I'm not a packager, I only follow devel to see what is coming down
the pipe as a user. I'm concerned about modularity. Like Michael, I
find rpm works fine for my use case, an individual workstation. I have
a couple of comments, but since I am not the target of modularity, take
them as curiosity.
It seems that modularity will create one more layer of indirection, so
security holes will be more prone to exist and be harder to find and
fix for the user, particularly on mixed rpm / modularity systems.
Modules are merely collections of rpms built in a special way.
Sometimes that's with macro definitions to force overrides for
specific configurations, and sometimes that's with filtering packages,
or customizing build and runtime content.
Modularity seems to be a workaround to avoid making the system fully
multi version. Admittedly, that is a lot of work, gcc has to be
modified to create a dictionary of libraries and api calls needed in
executables, libraries have to be modified to publish their api calls,
the kernel has to sort through multiple versions of a binary checking
priorities (somehow). rpm has to be modified to allow multiple version
installation, and to do library checking to be sure that an existing
library will cover needed calls. There has to be garbage collection for
libraries no longer needed by executables on the system. etc. The up
side is there is no more shared library so numbers for libraries, so
updates will *always* succeed, and the garbage collector will take
care of no longer needed packages. Is the following a good summarization
of the purpose of modularity? Modularity is a workaround using the
pareto principle to get 80% of the benefits of multi version with only
20% of the work.
RPM already allows multiversion installation with the caveat that
there are no file collisions. The other aspects are things that can be
handled by DNF. Modules are only about some of those use cases. The
other major cases involve build-time customization and partitioning
built packages into supportable or non-supportable groups.
Would it be practical to have a new hierarchy under /usr for
modularity, say /usr/mod, or move the current /usr to /usr/rpm and
let /usr be for modularity? This would make it easier to specify which
version of a binary to run, and which should be default in the path.
So, if I install a module with old, possibly insecure components,
because I need it for legacy purposes, I can specify it in a script, and
let the newer version be the default for general use.
No. It should be possible for modular content to become non-modular
and vice versa.
真実はいつも一つ！/ Always, there's only one truth!