Re: [fedora-java] dependency issues with java-1.4.2-gcj-compat
by Gary Benson
David Farning wrote:
> On Thu, 2005-09-15 at 13:42 +0100, Gary Benson wrote:
> > David Farning wrote:
> > > When running yum install eclips* I got all sorts of
> > > /usr/bin/rebuild-gcj-db: No such file or directory
> > > errors until I manually installed java-1.4.2*
> >
> > It sounds like rpm is _still_ not ordering dependencies correctly.
> > There should be a bug open against rpm for this, but if not please
> > file one.
>
> I did a bit of searching on this it would seem to be the
> %if %{gcj_support}
> ....
> Requires(post): java-gcj-compat >= 1.0.31
> Requires(postun): java-gcj-compat >= 1.0.31
> ....
>
> are causing problem because they don't...wait for it...work!
That's the one.
> Would there be a problem with
>
> %if %{gcj_support}
> ....
> Requires: java-gcj-compat >= 1.0.31
> ....
>
> ie. would it hurt it -compat were present all the time not just
> during post and unpost?
The Short answer is no, since Requires(*) implies Requires.
The long answer is that Requires on its own is not in force during rpm
transactions. Augmented Requires(*) dependencies specify that it must
be present at certain points within the transaction _in_addition_to_
inbetween transactions.
Cheers,
Gary
own,
Requires on its own.
18 years, 7 months
Improving Fedora javadoc
by Anthony Green
There are a couple of big problems with our javadoc situation right now:
- We don't install javadoc for the core classes.
- There are no links between javadoc packages.
If would be nice to fix this for FC5.
Here are my suggested actions:
1. If we aren't going to modify the gcc spec file to generate libgcj
javadoc, then we should use something like this package, which builds
core javadoc from the libgcj-src RPM...
http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm
2. Modify all our spec files to include links between packages.
3. All the javadoc gets installed in directories
under /usr/share/javadoc. It would be nice if there were a top level
index.html to tie them all together. We could add a %post(un) script to
maintain this file.
4. The Eclipse help system should refer to this top level index.html, so
it shows up along with the other Eclipse docs. Maybe it could also go
on the main Gnome menu under Applications/Programming.
Any other ideas? It all starts with [1], which we've discussed before
but I'm afraid we're kind of stalled on.
AG
18 years, 7 months
dependency issues with java-1.4.2-gcj-compat
by David T Farning
I just got around to installing native eclipse on the devel branch and
have found what appears to be a dependency issues with
java-1.4.2-gcj-compat.
When running yum install eclips* I got all sorts
of /usr/bin/rebuild-gcj-db: No such file or directory errors until I
manually installed java-1.4.2*
(I didn't keep a log cause I wasn't sure what was happening yet)
When attempting to yum remove eclipse*
I get the following
....
Removing : xerces-j2 #######################
[ 1/65]
Removing : eclipse-jdt-devel #######################
[ 2/65]
Removing : ant-nodeps #######################
[ 3/65]
Removing : eclipse-pydev #######################
[ 4/65]
Removing : ant-apache-bcel #######################
[ 5/65]
Removing : ldapjdk #######################
[ 6/65]
Removing : jakarta-commons-httpclient #######################
[ 7/65]
Removing : ant-jsch #######################
[ 8/65]
Removing : ant-apache-resolver #######################
[ 9/65]
Removing : ant-trax #######################
[10/65]
Removing : geronimo-specs-compat #######################
[11/65]
Removing : xalan-j2 #######################
[12/65]
Removing : mx4j #######################
[13/65]
Removing : eclipse-platform-devel #######################
[14/65]
Removing : ant-jdepend #######################
[15/65]
Removing : jakarta-commons-collections #######################
[16/65]
Removing : jakarta-commons-fileupload #######################
[17/65]
Removing : java-1.4.2-gcj-compat #######################
[18/65]
Removing : jakarta-commons-logging #######################
[19/65]
/var/tmp/rpm-tmp.61501: line 1: /usr/bin/rebuild-gcj-db: No such file or
directory
error: %postun(jakarta-commons-logging-1.0.4-2jpp_6fc.i386) scriptlet
failed, exit status 127
Removing : eclipse-rcp-devel #######################
[20/65]
Removing : jakarta-commons-dbcp #######################
[21/65]
Removing : ant-javamail #######################
[22/65]
...
The /usr/bin/rebuild-gcj-db: No such file or directory error shows up
just after java-1.4.2-gcj-compat has been removed.
If I manually reinstall java-1.4.2-gcj-compat I can successfully remove
jakarta-commons-logging.
Should I look into this deeper and file a bug report?
-dtf
18 years, 7 months
jpackage-utils on FC4 (x86_64 issue mainly)
by Carwyn Edwards
Why does macros.jpackage in jpackage-utils-1.6.3 on FC4 still use
%{_prefix}/lib/jvm references while jpackage.org macros.jpackage in
jpackage-utils-1.6.4 (1.6.3 too allegedly) uses %{_libdir}/jvm?
The really confusing part is that FC4 seems to have picked up
jpackage-utils up _after_ the change was made in the jpackage.org
version!? (around 1.6.3 when the chagelog lists the change at 1.6.2).
The end result is that the FC4 x86_64 gcj-compat package is in
/usr/lib/jvm rather than /usr/lib64/jvm. The unfortunate thing though is
that the link part of the alternative slaves also end up pointing at
/usr/lib/jvm.
I hit this while trying to finish off the Jpackage jdk cleanups I
started a while back. Updating to jpackage-utils 1.6.4 from jpackage.org
then trying to install a x86_64 Jdk built against it fails if the
gcj-compat package is installed as the alternatives link names are
different:
1:java-1.5.0-sun ###########################################
[ 14%]
link /usr/lib/jvm-exports/jre incorrect for slave jre_exports
(/usr/lib64/jvm-exports/jre jre_exports)
The culprit being:
--slave /usr/lib64/jvm-exports/jre jre_exports
/usr/lib64/jvm-exports/jre-1.5.0-sun
.. which of course conflicts with the link name already installed
against "jre_exports" for gcj-compat which lists jre_exports as being a
link from /usr/lib/jvm-exports/jre.
The workaround is to stick with the jpackage-utils in FC4 I guess. Still
it's a good example of how mixing JPackage and FC4 can cause problems.
Carwyn
18 years, 7 months
Java developer needed to help with Fedora Docs Project infrastructure
by Tommy Reynolds
Hi, All!
Over at the Fedora Docs Project, we have a problem that we think you
can help with. Our developers use XML DocBook so that we can
generate both HTML and PDF forms of the document from the same
originals. The HTML generation works great, but the PDF generation
is broken.
Our current tool "xmlto" uses TeX to render to PDF, but that hasn't
been maintained for a long time. We can use Apache FOP for the
rendering but don't want to use the JVM version because it doesn't
have an open license.
So, here is how you could help. We'd first like to get Apache FOP
native compiled using gcj and then maybe add in some open-source PNG
or JPG rendering libraries.
If you would like to help, you can reply on this list or contact me
privately at:
Tommy.Reynolds(a)MegaCoder.com
I look forward to hearing from you!
18 years, 7 months
Eclipse
by qwejustin
Does anyone know when eclipse will be updated next? My understanding is
that there have not been a update since 3.1.0_fc-0.M6.22
thanks
18 years, 7 months
GNU Classpath distro DevJam
by Mark Wielaard
Hi all,
Various Debian packagers and developers are interested in coming
together to improve the Free Software tool chain, the programs and
the free runtime environments for software written in the java
programming language.
For such a meeting we would like to include packagers from various
distributions to coordinate on library names, dependency and
versioning. And to share experiences on how to integrate and map
dependencies of tools like ant and maven when creating traditional
GNU/Linux distribution packages.
So we are proposing a developer and packager meeting around
coordinating and improving the state of packaging of large scale
applications written in the java programming language using the GNU
Classpath, gcj and other free java-like tool chains for the various
GNU/Linux distributions.
Please see DevJam wiki for details:
http://java.debian.net/index.php/DevJam
We hope to get together a group of (20 till 30) people wanting to do
some hands on hacking to show the state of the art in packaging.
Resulting in the availability of several new packages, improvements to
the free tool chains and cross-distribution packaging conventions
quickly after the meeting.
One of the ideas to keep the cost down for now is sharing the meeting
with another group in Oldenburg, Germany, from September 21st to
September 25th. http://meeting.ffis.de/Oldenburg2005/
If you are interested please add you name and thoughts about how to
make such a meeting most effective to the wiki! And please contact us
if you are interested in sponsoring the effort.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
18 years, 7 months
java-gcjHEAD-compat fixes
by Thomas Fitzsimmons
Hi,
I fixed some things in java-gcjHEAD-compat:
- removed the file conflicts with java-gcj-compat, so
java-gcjHEAD-compat will install cleanly beside other java-gcj-compat
installations
- added "javac" to the installed tools, using Gary's bootstrap ecj jar
Here are Andrew's instructions for creating a JPackage alternative for
GCJ HEAD:
https://www.redhat.com/archives/fedora-devel-java-list/2005-May/msg00046....
The installation of these packages runs smoothly now.
Tom
18 years, 7 months
