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

[bugzilla at redhat.com]

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 j.w.r.degoede at hhs.nl  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.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.