[Bug 193894] Review Request: ant-contrib - A collection of tasks for Ant

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ant-contrib - A collection of tasks for Ant

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193894

------- Additional Comments From [e-mail]  2006-06-29 11:54 EST -------
(In reply to comment #4)
> Hi Hans, thanks for taking the time to review this.
>
> Here are the updated files:
> http://people.redhat.com/ifoox/extras/ant-contrib.spec
> http://people.redhat.com/ifoox/extras/ant-contrib-1.0-1.b2.src.rpm
>
> These are all fixed except:
> > W: ant-contrib class-path-in-manifest /usr/share/java/ant-contrib-1.0b2.jar
>
> Do you know what the problem with a Class-Path element in a jar's manifest is?
> I'm not entirely sure why rpmlint is complaining here.

Nope, please ask / discuss this on f-e-l this is my first java package review.

About your fixes, they mostly look good, but:
* you now have this:
%if %{gcj_support}
if [ -x %{_bindir}/rebuild-gcj-db ]
then
  %{_bindir}/rebuild-gcj-db
fi
%endif
Twice under %postun, please remove it once.

* please dont use a patch like this:
Patch3:         ant-contrib-fileendings.patch
instead do : "sed -i s/\r// <file1> <file2>" on the problem files.

* You now have Release: 1.%{beta_number} that should be 0.1.%{beta_number}, so
that you can use "Release: 1" for the final. (see wiki).

* These must be removed (I missed them last time):
Vendor:         JPackage Project
Distribution:   JPackage
> These are all fixed as you described above.
> As for the symlink, I'm not sure why there's a symlink from a versioned
> docs directory to an unversioned one, but I decided not to remove it. I
> did take out all the weirdness with %ghosting and removing the directory
> and relinking.

OK.
> This is done in some packages in FC and the reason is that these packages are
> also built for RHEL, which currently doesn't use GCJ for java packages. It makes
> it significantly easier to maintain a single spec. Although I do agree that it
> makes the spec harder to read, I think the benefit for the maintainer of keeping 
> one spec file overweights that.

Thats a good reason, I've no problem with keeping gcj_support in that case.