On Wed, 9 Sep 2020 at 09:37, Björn Persson <Bjorn@rombobjörn.se> wrote:
Guido Aulisi wrote:
> IMHO we could package only the JDK and let the user use Java software directly from upstream.
> Usually upstream means Apache, which is a trusted source, and Java users are smart enough to manage the Java packages.
> I usuali do so when using maven, hadoop, tomcat, etc.
> I think this solution could be valid for any other language, like php, python: packaging only the base language and anything that is not available in executable formats.
And how well does that scale?
It doesn't scale.. but neither does having all those packages owned and looked at by 1 person. Either people need to start helping or this is the future. People have instead spent the last decade usually saying 'I need this but have no idea how to maintain it so you can't get rid of it.' That has led to the point where the people who were trying to do this made it into modules to make their lives easier and when that made other people's lives harder.. deciding that it was an unwinnable game so why participate any longer.
The cost of free packages is eternal vigilance on their maintenance.
As a sysadmin I don't normally need to know what language each program
is written in. I use language-specific tools only on programs I'm
developing, not on programs I merely use. Should I periodically run
cpan to check for Perl program updates, pip to check for Python program
updates, npm to check for _javascript_ program updates, gem to check for
Ruby program updates, and so on and so forth? And then manually check a
bunch of individual upstream websites for updates to programs that
aren't in those language-specific repositories either? No way! I run
"yum update" and get *all* the updates for my system.
Björn Persson
_______________________________________________
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
Stephen J Smoogen.
_______________________________________________ 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
