Stephen Gallagher wrote:
> The feedback that we (Red Hat) got about SCLs that was filtered down
> to Engineering was this:
But is that feedback relevant for Fedora, as opposed to RHEL?
> 1) Customers really like having the option to install the version of
> software that their applications needs from a trusted source (the OS
> vendor/distributor)
Fedora is normally about having the latest version of everything available.
(That's what the "First" in the 4 'F's stands for.) So it rarely happens
that the default version is too old. And if the default version is too new
for the user, that is generally filed in the PEBKAC category. ;-)
> 2) Customers really *dislike* needing to modify their software to
> understand the SCL enablement process.
That is a non-issue if everything uses the latest version, as it is supposed
to. And we never allowed SCLs in Fedora to begin with.
> 3) Customers very rarely need to install different versions of the
> same software on the same system. They use containers or VMs for
> separate applications.
I don't see this being the case for Fedora users at all. A container for
every single application is something some large-scale deployments of RHEL
may be doing. But the average Fedora user is a home user with one or two
(desktop and notebook) computers running a single Fedora installation each.
They do not want to have to deal with the added complexity of containers,
and container technologies such as Flatpak or Snap that try to hide the
container from the user do not allow the user to upgrade the libraries in
the container and so often suffer from delayed or absent security updates
(because the whole container or the whole runtime has to be respun by the
maintainer to provide them, and then the user has to upgrade to the respun
image).
So I think that having things in Fedora that are not parallel-installable is
not a good idea, at all. There is a reason that the guideline on Conflicts
says to avoid it at all costs, and that compatibility libraries, in
particular, are NOT allowed to conflict at runtime (Conflicts are only
tolerated in the -devel packages, and discouraged even there).
It really worries me that we are allowing Fedora-provided packages to depend
on arbitrary branches of modular packages (modular Fedora packages can
already do that, Ursa Major would apparently extend that possibility even to
normal packages), because that can easily lead to Module Hell (RPM Hell
2.0), where application A requires module Foo version n whereas application
B requires module Foo version m (and obviously versions n and m of Foo are
not compatible). So the user is stuck being unable to install applications A
and B from our repository. That is something that should NEVER happen in a
consistent distribution. (Avoiding that is the main job of a distribution!)
> So with Modularity, we opted to drop the parallel-installability
> requirement in favor of parallel-*availability* and the ability to
> keep the packages installing in the standard locations (/usr/bin,
> /usr/lib64, etc.)
>
> This *is* a net improvement for the vast majority of deployments.
Sure, the SCL hack with its non-FHS-compliance is a bad idea, too, but that
was never allowed in Fedora for a reason.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
