[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Modularity and the system-upgrade path
From:       Petr Pisar <ppisar () redhat ! com>
Date:       2019-11-19 10:52:27
Message-ID: slrnqt7ibb.6pv.ppisar () dhcp-0-146 ! brq ! redhat ! com
[Download RAW message or body]

On 2019-11-16, Kevin Kofler <kevin.kofler@chello.at> wrote:
> Petr Pisar wrote:
>> With your proposal Bugzilla packager would have to package Bugzilla
>> twice: as a normal package for default Perl 5.26 and as a module for Perl
>> 5.30. Then a user would have hard time to select the right combinations of
>> Perl and Bugzilla. It would double fork work pacakgers and and make
>> the system more dificult for users.
>
> The Bugzilla rebuild for the non-default Perl actually belongs IN the Perl 
> module. Otherwise, enabling the non-default stream for the Perl module will 
> break the user's Bugzilla and force them to manually enable the 
> corresponding non-default stream for the Bugzilla module. Plus, since there 
> are many Perl applications, having a module for each of them (each tracking 
> Perl's module streams) just does not scale.
> 
Adding Bugzilla in Perl module does not scale either. You have many Perl
applications and you should put them all into the Perl module. As
a result you would have a Perl module containing all Perl applications.
We now more than 3000 such packages. You can imagine that you were never
be eable to build such a giant module because there is always a package
that fails to build. Also whenever you want to provide a new
incompatible application you would have to fork the giant Perl module.
Do you want to have perl:5.30-with-Bugzilla-5.1.2-with-slic3r-1.3.0-...?

I believe that better approach is to meld modularity into RPM. So that
you can have plenty of small independent packages aware of parallel
availability.

> But what this example really shows is that it is a horrible idea to have a 
> Perl module to begin with. The non-default Perl needs to be packaged as a 
> parallel-installable compatibility package (or as an SCL, but that opens its 
> own can of worms) instead. You cannot just replace a language interpreter 
> (especially not one as widely used as Perl) with a different version. (As 
> you pointed out yourself, that breaks even fedpkg. Even though fedpkg itself 
> is not even written in Perl!) The parallel-installable approach is also the 
> only reasonable way to support applications that require a non-default 
> version of Perl, without conflicting with the rest of the distribution.
>
That's nice theory that will never come true becaue it would require to
make all Perl code parallel-installable. And Perl code is not only
libraries as in the Python language. That's also myriad of Perl scripts
that you want to have in PATH. If you start fidling with things in PATH,
you have the problem of SCL. And as you wrote, SCL is terrible. And that
was the reason why we have modularity: We do not want to relocate code
to non-standard paths.

I think it's inevitable that there will be conflicts and it's better to
have them managable with a package manager (i.e. having default
streams) rather crates few modules that silently overlay non-modular
packages whe a user enables them.

The parallel installablity is nice, but it's way more difficult than
parallel availability.

-- Petr
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]