[fedora-java] Re: raising Yum's IQ

David Walluck david at zarb.org
Fri Sep 16 19:19:50 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vadim Nasardinov wrote:
> I am a little fuzzy on why sharing exact same .spec files (modulo
> minor distro-specific patches) is infeasible.

I think it was at my behest that gcj_support was added to some spec
files. Anyway, the good news is that I have actually gone and taken a
lot (if not all!) FC spec files and added `%if %{gcj_support}' in the
appropriate places. I just have been strapped for time so I haven't done
much of anything with these packages. Similarly, I really have very few
additions I would like to add to eclipse (wrt jpackage), I just haven't
had time to do it. So I don't blame Fedora here at all, but myself,
since I've actually already done this work and just can't seem to find
the time to do the last step.

Also, I obviously am not here to dictate Fedora policy, and we know that
without Fedora, the eclipse 3.1 work may never have gotten done. The
only thing I am in favor of, though, is a policy that might integrate
better cross-distro and/or avoids duplication of work (since I am sure
we all don't have the extra time).

In the end, I would prefer two separate spec files for each. It is
actually possible to do something with the rpm build scripts to perhaps
generate such a package 100% automatically (just as debuginfo packages
can be automatically generated now). The inability of rpm to have a
noarch subpackage of an arch package prevents what I'd call a near-ideal
solution. Already we have aot-compile-rpm in the rpm build scripts but
it's not being used. But I think this is a step in the right direction.
Perhaps a second rpmbuild process could be launched on the automatically
generated native spec file from the non-native build.

- --
Sincerely,

David Walluck
<david at zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDKxrVarJDwJ6gwowRAiKYAJwNAtjiMeg4NHLRthx0aLvBSAxN5gCgnvZi
7ZrTPKKAjQIZSP8JkNm4yHI=
=sxNz
-----END PGP SIGNATURE-----




More information about the java-devel mailing list