I think there's a difference between libraries and applications though.
I for one think that not having Eclipse packaged in Fedora/RHEL etc.. would be a big loss, the same goes for Mission Control which we maintain
On Wed, Sep 9, 2020 at 5:00 PM Aleksandar Kurtakov <akurtako@redhat.com> wrote:
>
>
>
> On Wed, Sep 9, 2020 at 5:33 PM Stephen John Smoogen <smooge@gmail.com> wrote:
>>
>>
>>
>> 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.
>
>
> Couldn't agree more!!! From big proponent of RPM packaging I went to the "meh, who cares" group - because I see more and more things coming our way for maintenance so the choice in front of us is "work on upstream Eclipse" or "keep Eclipse RPM packages". One can easily guess what wins.
>
>>
>>
>> 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@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>>> 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@lists.fedoraproject.org
>>
>>
>>
>> --
>> Stephen J Smoogen.
>>
>> _______________________________________________
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>> 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@lists.fedoraproject.org
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> 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@lists.fedoraproject.org
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com><br>9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898