10.05.2017 09:13 Patrick Huang <pahuang(a)redhat.com> wrote:
Like Rafal said it's because fedora doesn't come with
a lot of the java packages pre-installed. [...]
I don't think it's wrong. If you need those java packages
you can easily get them; if you don't need them you are
not forced to have them.
[...] With yum/dnf, if you need package A, and A needs B.
Even though you don't require B, it still pulls it for you.
I neither think it's wrong. If you need A and A needs B
then you also need B (even if you think you don't need)
because A will not work without B. Unless you mean:
To make it worse, a lot of the java library packages
bundles multiple jars (the smallest library artifact
java build tools uses). This means even if you just need
one jar in your actual build, you have to install the
whole rpm that comes with more than you need.
So probably the solution would be to split A into
A-subset-required-by-zanata (which doesn't require B)
and A-subset-required-by-other-project (which requires B)
and so on.
RPM subpackaging will help
Definitely, this is one of the solutions.
but AFAIK a lot of the packagers don't care or won't
bother doing that.
Like Brian said, the other part of the solution would be
to approach the packagers and help them package correctly.
If splitting is the correct solution.
Not to mention you have no/very little control of what
version of the library you are getting from yum...
You get the latest. Is there any reason why you wouldn't
want the latest? Isn't the latest the best? Does it have
bugs? Then fix them, report bugs, test early so the developers
fix the bugs on early alpha/beta stages. Is it incompatible?
Then it means you need A1.rpm, A2.rpm, and so on (multiple
backward compatibility versions like python2 vs. python3
or java-1.7.0 vs. java-1.8.0).
[...] Will switching to another language help?
No, I don't mean switching totally and dropping the
existing Java project. Like Alex and Carlos said, the Python
client is community based and anyone can write another
client in a preferred language if they want.
So, summarizing, here are the solutions I can see:
1. Accept as it is because it is correct. DNF provides you
an easy way to install all dependencies. The same would do
all other applications: if they need a specific library stack
and you don't yet have it installed it will pull lots of
dependencies.
2. As Brian said, help the packages package correctly:
split the packages into even more subpackages so you as
a user get only those dependencies which you really need.
But would it be better? Split every package into dozens of
smaller subpackages mostly consisting of a single jar file?
Wouldn't the result be that again we'll have ~100 dependencies
except that they would be smaller? Isn't it similar to the
situation we currently have? Are those ~100 required RPM
files large?
3. If there are people who don't like Java (I don't mean
literally don't like but don't have it installed because
don't need it and would be forced to install all those
dependencies only because they are going to use zanata-client)
then write another client in your favourite language
which will use other dependencies which may also count
as much as ~100 but you will not notice them because you
likely already have them installed.
4. Another solution which comes to my mind is to prepare
a kind of a "static build": a package which will bundle
all required jar files. It may be huge but will have few
external dependencies and maybe will be smaller than a total
sum of all required dependencies now. Maybe it would be
better for the people who need zanata-client and no other
Java applications and are forced to install those
dependencies only because of zanata. Of course, by bundling
I mean bundling them with Java libraries, not JRE itself.
Regards,
Rafal