It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
Florian Weimer / Red Hat Product Security Team
I logged a bz (https://bugzilla.redhat.com/show_bug.cgi?id=990588) to
request that the tomcat shell scripts (catalina.sh and the rest) be
packaged. I've had some discussions with the person the bz is assigned
to and few others, but no one knows why the scripts were not packaged.
Nor, it seems, does anyone see a problem with them being packaged as far
as I can tell.
Does anyone know some history here?
Hi Java folks,
The current netty in Fedora is 3.6.3. There are newer updates to 3.X series
upstream but also for some time now 4.X series has been available. In the
spirit of keeping the most up to date version in our distro, I aim/plan to
update this in rawhide in the coming weeks. However, there have been some
changes upstream that any maintainers of packages which depend on netty will
need to be aware of. Those packages are:
In addition, we currently have a compat netty31 package, which is used only
by the eucalyptus package. I'd also like to encourage the maintainer of
eucalyptus to look into porting to the newer netty, so this longstanding
compat package can be retired. (Well, there are other packages that
"repoquery --whatrequires netty31" returns, but inspection of .spec shows
that they only Require: netty without a version; only eucalyptus has an
explicit requirement for netty31.)
So, what are the implications of this update? Well, upstream netty has
moved from being a jboss project to being independent at netty.io, and has
changed their package namespace accordingly. In addition, some key API
classes have slightly changed names. Finally, and I haven't looked deep at
this part yet, but it seems there are some other incompatible API changes.
Any package currently using netty will *at least* require a search-and-
replace for package/class name changes, and may require more indepth fixes
in order to work with the most recent upstream releases.
The bulk of the changes came with the 4.0 release, and conveniently enough
upstream made a single commit updating most of their example code at once
which is likely to be a good reference for anyone porting an application.
I'll be starting on this work around mid-November. My plan is to first
create package of the newest netty release at the time but not push to
rawhide just yet, rather make srpm available to interested maintainers via
other means. Then, as co-maintainer of thermostat, I will help to port that
package to the new netty API. I hope around this same time maintainers of
other packages will do same. To me, this will act as "sanity check" for the
updated netty package, and if this check is successful, I'll then push the
netty changes to rawhide. If all goes well, this should be done by the end
of November (modulo a week or so).
Please, if you have any concerns with this plan, speak up! Otherwise, wait
for my email in a few weeks with .srpm to play with :)
P.S. I *really* hope that at the end of all this we are not left with *two*
compat packages for netty, ie I hope that either eucalyptus is able to port
or that all of the others are able to port, or even better both of the
On 28 December 2013 16:43, Bruno Wolff III <bruno(a)wolff.to> wrote:
> Notes that you need to use lua in pretrans scriptlets, not shell commands.
Thanks. I've already seen that. It doesn't seem to make any difference
whether it's a bash scriptlet or a lua scriptlet, though; irrespective
of what language is used to delete the symlink, the problem still
> I haven't found an example for you to copy, but note there are still some
> cases where changing symlinks to directories or vise versa won't work with
> rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909).
I think deleting the symlink manually may be revealing a problem in
rpm. It seems to treat /usr/share/javadoc/test-1/hello (from the old
package) and /usr/share/javadoc/test/hello (from the new package) as
the same thing. Since the new package is installing
/usr/share/javadoc/test/hello, it therefore decides to 'skip' the old
'hello' file, rather than 'erase' it.
I'm not sure yet why these two paths are considered to be the same...
This is just a quick heads-up to let you know that I am updating
FindBugs to 2.0.2 in F19 and F20.
A few dependencies have also been updated:
* jFormatString has been updated, but only FindBugs depends on it.
* findbugs-bcel has been updated to a snapshot of the BCEL trunk.
* jsr-305 has been updated by a couple of Subversion revisions. I
don't believe the changes will have any effect on dependent packages.
Excluding packages that depend on jsr-305, packages that I think could
be affected are:
TrueZIP looks like it just has a build-time dependency on FindBugs
(the code uses FindBugs annotations). Given that FindBugs 2.0 is
advertised as "a drop-in replacement" for 1.3.9, I don't anticipate
As for Gradle: I know this has been retired
but is still in F19. I might try to figure out if Gradle is broken by
the FindBugs update, but I'm wondering if it's worth the effort. Does
anyone have any opinion?
I've just submitted the F20 update
stable. Assuming there are no objections/problems, I'd like to submit
the F19 update (https://admin.fedoraproject.org/updates/FEDORA-2013-20181)
in the next couple of days.
I am no longer working for Eucalyptus and am orphaning all related packages.
What's new in XMvn 1.4.0
XMvn 1.4.0 was released on 2013-12-09. Most important changes
* Minor features
* Limited support for absolute JPP artifact files
Artifact files specified as absolute paths pointing to arbitrary
locations are now allowed. They are implemented as symbolic
links which are pointing to the primary artifact file, which
must be explicitly specified as non-absolute file.
Appropriate suffixes are added depending on artifact version,
classifier and extension. As absolute symlinks can be placed at
any location, configured repositories are not taken into account
and flat repository layout is always assumed.
Absolute symlinks are only created for artifact files and
attached artifacts, but not for POM files. Absolute files for
artifacts with no files (i.e. POM artifacts) are silently
* Minor bugfixes
* Fix NullPointerException bug in installer code
* Allow file installation in root directory
XMvn was unable to install files in root directory because of
false assumption that every directory has a parent. This was
fixed in version 1.4.0.
I would like to share a quick tip on how to solve class loading
conflicts when both asm3 and asm4 libraries are on class path. Upstream
projects usually solve this problem by bundling shaded versions of
asm3/asm4, but due to "no bundled libraries" rule this trick cannot be
used in Fedora.
Our objectweb-asm3 package now provides shaded versions of all artifacts
in this package (in addition to original ones). Only difference between
original artifacts and our shaded artifacts is that all classes have
been relocated from "org.objetweb.asm" to
"org.objectweb.distroshaded.asm" package. gId:aId of these shaded
artifacts is the same as gId:aId of their original counterparts, but
they have classifier "distroshaded".
So if upstream of your package bundles asm3 and unbundled version causes
problems somewhere, then you can simply change the "org.objectweb.asm.*"
imports in .java files and add proper deps/requires on shaded asm3
artifacts (e.g.: "asm:asm-all::distroshaded:").