Le 2019-07-22 21:04, Jeremy Cline a écrit :
On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:
On ma, 22 heinä 2019, Jeremy Cline wrote:
It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maintaining them grows a lot. In 2019 Fedora Java packages got dropped
by one of maintainers and that created a havoc as many packages depend
on few important ones that were suddenly not supported anymore and
were
going to be orphaned.
The same is, I think, true of many other languages. I think it's a sign
that our approach to packaging is going to have to change. Just looking
at the package stats by language at https://libraries.io/ and comparing
it to the size of the Fedora repositories is telling.
It is true of most languages. That’s one core reason Fedora is failing
to integrate new big apps (the must-have apps like Apache or Bind were
at the turn of the century). Dev tooling has improved a lot in the last
20 years. rpm was “done” and received minimal maintenance. As a result
devs are shoveling bad code faster than entities like Fedora manage to
integrate it. No packager can handle the amount of upstream churn, when
upstream is armed with all kinds of automation and refactoring helpers,
while packagers are expected to hand-craft everything like 20 years ago.
rpm urgently needs a major rework to work efficiently with 2019 source
code (integrate properly with git sources, auto-generate as much as
possible, help packagers identify critical cycle break points that need
fix up upstream). Or be replaced by something else that does all this.
Not another workaround/papering over/templating addon to limit the pain.
Not a module system designed to contain the extent of rpm inadequacies.
Not a rewrite of spec files in yaml without any other improvement.
A real update of our kernel of packaging tools.
The core rpm design has aged well. But, it’s being constrained by old
bugs, that were acceptable when the amount of packaging was way smaller.
And it’s not being applied to 2019 problems. In fact the rpm core design
must be terrific, for rpm to keep somewhat relevant in 2019, when it
still has not acknowledged the web exists (it‘s been work-arounded with
the awful # hack in urls).
So it all comes back to the level of investment question.
Do rh want to invest in the RHEL/Fedora core, like its future depended
on them, and keep it relevant or interesting. Or does it intend to let
it slip into comfortable legacy land like the proprietary unixes it
replaced, and contributors interested in longer term effects than the
next 5 years of RHEL should just look for another hosting organization?
Is Fedora’s future just some form of glorified firmware, with no
higher-level app included?
Without a major rework it will slowly become limited to the packaging of
software that was written at the same time, with the same convention,
and Fedora as a packaging org will become a legacy pile.
rpm, dnf, koji, pagure… they’re all components of the general packaging
experience stack. Dropping some of them means the project as a whole
does not believe in its own future.
Regards,
--
Nicolas Mailhot
_______________________________________________
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
