[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:       Kevin Kofler <kevin.kofler () chello ! at>
Date:       2019-11-19 16:20:29
Message-ID: qr14oe$5ep4$1 () blaine ! gmane ! org
[Download RAW message or body]

Petr Pisar wrote:
> 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.

But the scripts do not need to care about the version of Perl you are 
running, do they? It matters for compiled code, but why for Perl scripts? 
Those can just run with the default version of Perl if they support it, or 
with the shebang line changed to something like #!/usr/bin/perl5.30 if 
that's what they require.

> 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 agree that the SCL approach is not optimal, but letting the versions just 
conflict is much worse!

The best way to deal with conflicts in PATH is to suffix the binaries, not 
to move them. But that is only needed when it makes a difference for the end 
user which version they run. If the executable script "foo" does the exact 
same thing when run under Perl 5.28 or 5.30, then you need only one 
/usr/bin/foo set up to run against the distribution default Perl, the other 
one is redundant (which is the nice thing about parallel installation: you 
do not have to support running all the executables under a non-default Perl, 
only those that actually need it).

> 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.

I think that any model that has conflicts is not workable for the Fedora 
user base. Desktops and small servers are not normally containerized, so 
being able to install different applications without conflict is a non-
negotiable requirement.

I see only 2 ways to provide a newer Perl for Fedora:
1. as a parallel-installable compatibility package, or
2. as a grouped official Bodhi update including a rebuild of all packages
   depending on the old Perl ABI
(and only the first one is suitable if you wish to provide an older Perl, 
because you should not be downgrading the system Perl).
Failing those, the only option is really:
3. just don't do it.

Providing a perl:5.30 module replacing the system Perl (and breaking 
everything in the distro depending on it) is essentially useless and does 
not provide much value over option 3.

        Kevin Kofler
_______________________________________________
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]