Re: WildFly status (and future) in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Do we really need to insist java applications like WildFly and Eclipse
are fully
decomposed down to individual RPM's ?

I understand very well reasoning from both sides. Decomposing makes it
easier to track packages that need to be updated (CVE's) because the
idea is to have only one place in the system where you need to patch. On
the other hand - different projects have different schedules and
requirements, so managing all of them to use a specific version of a
specific libbrary is very hard, it's time soncuming and sometimes
impossible. This leads to frustration and to escape from the
packaging/maintining work. I'm currently in that phase.


Could it not be sufficient (and easier) to just have one big RPM for
this ?

Basically you're talking about this (I announced it some time ago in
this thread):

https://copr.fedoraproject.org/coprs/goldmann/wildfly/

This is still a valid RPM, but it's not built in the Fedora way.

More talking in the middle - drop the need for individual synced rpm's of each jar, but still track which rpm's contain what jars/sub-rpms so CVE's etc. can be handled.

The Copr won't make it into any fedora repo, but yes, its surely the simplest way.

Isn't a lot of this done by EAP prod team anyway, can't that work be reused/shared to
avoid it all hang on one person  ? :)

/max
http://about.me/maxandersen
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel




[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux