Stephen Gallagher wrote:
> On Wed, Nov 13, 2019 at 5:29 PM Kevin Kofler <kevin.kofler@xxxxxxxxx>
> wrote:
>> What about libgit2, was that not a default stream?
>
> It was not. It was a dependency of other modules.
So it looks like we really also (in addition to the proposed ban on default
streams) need a ban on non-leaf modules. It would also fix the version
conflict issue.
You have stated yourself: "If you have a library that can be installed in
parallel, make a compat package. Modularity is not the correct solution for
that case". And any library can be installed with parallel given sufficient
packaging skills.
>> And what we are missing here is a list of modular packages with no
>> default version at all (i.e., neither an ursine build nor a default
>> stream), a state which is completely broken (but which seems to currently
>> exist in Fedora, unfortunately).
>
> Could you define "broken"? Because I have no idea what you're talking
> about here. If it is module-only and has no default stream, it means
> it's effectively invisible unless you enable a stream knowingly.
That is exactly what I mean by "broken": The packages are not discoverable
unless you enable some module first, and they are not installable without
opting in to the potential replacement of arbitrary system libraries (or
"frameworks") (e.g., Django getting downgraded by the ReviewBoard module),
which may or may not actually be possible without conflicts on the specific
installation.
I should be able to just dnf install the packages that I want (or
point&click-install them in Dnfdragora) and get some version (which may or
may not be the latest) that works with the distribution libraries (which
also may or may not be the latest). If the application does not work with
the default version of the library, if no version of the application that
works with it is available, and if the application cannot be patched to port
it to the system version of the library, a compatibility version of the
library is needed. This also holds for programming language interpreters
(such as Node.js), sets of libraries (such as the Node.js packages), or
"frameworks" (such as Django, which are really just one of the preceding or
a combination thereof). I consider it the whole point of a distribution to
package the software in such a way. If I get to deal myself with
incompatible version requirements, I may just as well install the
applications directly from upstream.
>> (Please note that I also read those 2 points as implicitly banning
>> filtering packages from modules, but if that is not obvious to someone,
>> then it should be added as a separate rule.)
>
> It does not implicitly ban filtering packages. It implicitly bans
> filtering out *sub*-packages. It still think it's acceptable to filter
> out *all* produced subpackages of a component that is used only at
> build-time.
I do not see how that makes a difference, considering that banning some or
all subpackages behaves exactly the same way. In both cases, the filter will
interfere with versions of that component packaged elsewhere (see the
complaints about the filters in RHEL). In both cases, you are deliberately
hiding a component that you packaged from users and making it hard to
obtain. In both cases, you are hindering cooperation and risk introducing
conflicts (when other maintainers will do the logical thing and repackage
that component elsewhere because you won't let them use the version you
packaged).
And both violate the rules I am proposing ("1. any package that exists in a
module MUST have a default version and 2. that version MUST be packaged in
the ursine/non-modular repository, not as a default stream") in exactly the
same way (because those subpackages or entire packages definitely do EXIST
in a module, even if you are hiding them).
> This is literally the entire point of a distribution. We provide an
> opinionated collection of software packaged for people to use.
I think the point of the collection of software packaged in a distribution
is not to be opinionated, but to be consistent and interoperable. That it
sometimes ends up being opinionated is an unfortunate side effect (mostly
caused by upstreams refusing to listen to user requests, forcing the
distribution maintainer to make a decision on which side to irritate). It
should NOT be the goal. Being consistent and interoperable should. And that
is exactly what Modularity is endangering.
The remainder of your message (your last 3 paragraphs) has been answered
quite well by John M. Harris, Jr. already, so I am not going to repeat the
same thing.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
