Rahul Sundaram wrote:
Les Mikesell wrote:
In fact, I don't
see any reason any java code needs to be specialized for a
distribution or included in its own repository. Why not just make
fedora work with an external repo for java that works across
distributions/versions and avoid the issue entirely instead of
shipping something that isn't quite java? Even when a real java can
be included, what is the point of having specialized distro/version
packages of the apps that don't need specialization?
There is no "specialization" usually necessary for including software in
the repository.
Why does jpackage.org have all those separate repository entries for
different distros/versions if they could all be the same?
Fedora avoids specialization by being close to upstream
usually. Relying on a external repository for Java would mean that we
can't include any Java programs within Fedora.
I'm very agnostic about where something comes from. Why should anyone
care about that?
Parts of Openoffice.org,
Eclipse and dozens of programs were introduced into the repository
because of the work that went into GCJ, classpath etc and even OpenJDK
has benefited from that now.
Being 'introduced to your repository' isn't particularly interesting to
me. I'd much prefer to not be trapped by what happens to fit your
policy this week. Why not include the config for the jpackage repo and
let yum sort out where things come from?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
