> Am 08.10.2021 um 14:08 schrieb Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx>: > > Peter Boy wrote: >> A valid point, but only in case the app that consumes the maven artefact >> in unmaintained. > > Many applications are maintained and never (or very rarely, only when they > encounter some issue with the version they currently use) bother bumping > their dependencies after adding them once. Especially in the corporate > world, this is commonplace. Yes, unfortunately in case of security issues. But those people wouldn’t be amused either if you silently exchanged a lib/jar. As a Fedora rpm, the app will get rebuild about every 6 months. The „curated list“ as proposed/implemented by Mikolaj keeps track of upstream maintenance and security issues (at least it is constructed to be able to do as he described). So we can make a rebuild fail if it uses a security tainted version instead of a newer one. That would be quite a broad hint. If someone ignores that, the problem is not one of jar vs. rpm. >>> I think this would be not only a huge >>> waste of space >> >> given the current size of hard drive space, this really isn't a problem. >> You won't be able to install a meaningful collection of apps whose >> cumulative footprint of jars installed in parallel leaves any noticeable >> trace on a x tb disk. > > Considering that Fedora now also targets devices with as little as 16 or 32 > GB out-of-the-box storage: > > https://fedoraproject.org/wiki/Architectures/ARM/PinePhone > https://wiki.pine64.org/index.php/PinePhone#Specifications > > that argument is invalid. Boxes with these storage limitation have usually other limitations as well and are not a device to install a huge bunch of software. But even with 16g GB storage, what is a typical size of jars? E.g. the set of log4j jars need about 2mb. You need a lot of jars installed redundantly to flood 16 gb of storage. In theory you are right, but practically this will not be a problem in the vast majority of cases. And in any case, it is better to have applications as rpm for a large number of typical usage scenarios than no rpm version at all for anyone. All that under the assumption that said „curated list workflow“ will make it easier to build a Java application rpm. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
