Stephen Gallagher wrote:
> To be clear, I am reading every single reply to this thread very
> carefully. We *will* be taking all of this feedback into consideration,
> but please understand that we're also trying to balance things. As Neal
> noted upthread, we do have a responsibility to our downstream to make sure
> that we do not break the ability to manage default streams. This becomes
> much more difficult if we cannot have them in Fedora, because the testing
> of them is lost.
It has been repeatedly stated that Fedora is NOT a beta version of RHEL. So
it must not be treated as one.
Fedora needs to ship what makes sense for Fedora, not what makes sense for
RHEL.
> We are absolutely considering the option of disallowing default streams in
> Fedora, but we *really* don't want to rush into that. For one thing, we do
> have a number of packages that have moved to modules-only that would have
> to convert back.
Well, yes, they would. But it is better to do it now than to wait until even
more packages are affected.
If the wrong decision to use default streams had not been made to begin
with, we would not have to do this extra work now! And the longer we wait,
the worse it will become. So let's fix things as quickly as possible!
No matter how far down the wrong road you have gone, turn back. (That
sentence is frequently quoted on the Internet, it is allegedly a Turkish
proverb.)
> For some projects, this is probably just an annoyance, but for others this
> may be a major impediment. In particular, one of the advantages of
> Modularity is the ability to have buildroot-only packages that are
> different from the base operating system (and don't end up delivered as
> artifacts from the module). There are likely modules out there that rely
> on this behavior because their build requires a newer or older version of
> some package than the non-modular buildroot provides.
The whole concept of buildroot-only packages is incompatible with the
definition of Fedora as a self-hosting system and should never have been
allowed. I agree with Neal Gompa that it is absolutely anti-community. In
addition to the points he already stated, that misfeature makes it painful
for users to rebuild the packages, or to compile other software with the
same build requirements.
If the package truly needs a different version of the dependency (and cannot
be fixed to work with the system version), compatibility packages with a
versioned name can be introduced.
But in most cases, buildroot-only packages are actually being abused to hide
the only version of a package used at build time from users, because the
maintainer does not want to "support" the package for some reason. This is
obviously the worst in RHEL, where the decision to not support something is
probably taken by management, but reportedly, this situation (packages
private to some module) also exists in Fedora, where there is just no valid
reason to do that.
> I'm wary of assuming that this thread represents the whole of Fedoran
> opinions, however. As we all know, it's generally the set of people who
> are upset that speak up the loudest.
But that does not imply that they are a minority. It is too easy to discount
criticism as coming from a "vocal minority" with no evidence whatsoever. And
as far as I can tell, the only people speaking out in favor of default-
enabled Modularity in this thread are directly involved with the Modularity
WG, all other packagers who replied support Miro's proposal.
> I'm not discounting your concerns (far from it!), but if we only base
> development decisions on "make sure no one is upset about it", we'd never
> accomplish anything new at all.
That wrongly assumes that you cannot innovate without breaking things.
Innovation can and ought to be done in a way that does not upset people.
> I've been trying to carefully describe both the use-cases and the
> technical limitations (both intrinsic to the design and those that are the
> result of imperfect implementation) each time. It's somewhat disheartening
> to hear responses that largely boil down to "If you can't get it perfectly
> right, stop trying!".
If, just from the design, it is possible to prove by simple logic that the
system will not work no matter the implementation (which is the case with
Modularity because the design allows modules to require a specific non-
default version of another module while not allowing 2 versions of the same
module to coexist, so it is a recipe for version conflicts), then yes, it is
better to stop trying.
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
