Bug 225928 - Merge Review: jakarta-commons-el
Merge Review: jakarta-commons-el
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fernando Nasser
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 14:09 EST by Nobody's working on this, feel free to take it
Modified: 2009-09-26 10:18 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-09 12:00:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fitzsim: fedora‑review+


Attachments (Terms of Use)
Spec file (7.89 KB, application/octet-stream)
2007-02-07 18:14 EST, Fernando Nasser
no flags Details

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 14:09:14 EST
Fedora Merge Review: jakarta-commons-el

http://cvs.fedora.redhat.com/viewcvs/devel/jakarta-commons-el/
Initial Owner: fnasser@redhat.com
Comment 1 Fernando Nasser 2007-02-07 18:14:39 EST
Created attachment 147611 [details]
Spec file
Comment 3 Thomas Fitzsimmons 2007-02-08 22:07:04 EST
MUST:
* is this appropriate for Fedora?
X rpmlint on jakarta-commons-el srpm gives no output

  $ rpmlint /home/fitzsim/rpmbuild/SRPMS/jakarta-commons-el-1.0-7jpp.1.src.rpm
  W: jakarta-commons-el non-standard-group Development/Libraries/Java

  Group should be just: "Development/Libraries".

  Here's a list of valid groups:

  http://fedoraproject.org/wiki/RPMGroups

  $ rpmlint
/home/fitzsim/rpmbuild/RPMS/i386/jakarta-commons-el-javadoc-1.0-7jpp.1.i386.rpm
  W: jakarta-commons-el-javadoc non-standard-group Development/Documentation
  W: jakarta-commons-el-javadoc dangerous-command-in-%post rm
  W: jakarta-commons-el-javadoc dangerous-command-in-%postun rm

  Group should be just: "Documentation".

  Why the %post/%postun sections?

  %post javadoc
  rm -f %{_javadocdir}/%{name}
  ln -s %{name}-%{version} %{_javadocdir}/%{name}

  %postun javadoc
  if [ "$1" = "0" ]; then
      rm -f %{_javadocdir}/%{name}
  fi

  %files javadoc
  %defattr(0644,root,root,0755)
  %doc %{_javadocdir}/%{name}-%{version}
  %ghost %doc %{_javadocdir}/%{name}

  Why not just include the symlink in the javadoc subpackage and eliminate the
  use of %post, %postun and %ghost?

* package is named appropriately
* specfile name matches %{name}
* package meets packaging guidelines.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package and marked with %doc
* specfile written in American English
* specfile is legible
* source files match upstream
* package successfully compiles and builds on at least x86
* BuildRequires are proper
* find_lang usage correct
* package is not relocatable
* package owns all directories and files
* no %files duplicates
* file permissions are fine; %defattrs present
* %clean present
* macro usage is consistent
* package contains code
* no large docs so no -doc subpackage
* %doc files don't affect runtime
* gcj .so files need not be in a -devel sub-package
* no pkgconfig or header files
* no -devel package
* no .la files
* desktop file
* not a web app.
* file ownership fine
* binary RPMs function on x86
* final provides and requires are sane

SHOULD:
* package includes license text
* description and summary sections don't have translations (OK)
* package builds in mock
* package builds on i386
* package functions as described
X scriptlets should be sane

  See above questions about %post and %postun sections.

* no -devel package
* no pkgconfig files
Comment 4 Kevin Fenzi 2007-02-08 22:55:43 EST
Hey Thomas. 

The current way we are doing these reviews is described at: 
http://fedoraproject.org/wiki/WarrenTogami/ReviewWithFlags

So, you should set the 'fedora-review' flag to - and reassign back to the 
owner/submitter to fix items you see in your review. Then when they do so, 
they should add a comment, change 'fedora-review' to ? and reassign back to you
to look over. Once you approve the package reassign the review back to the
submitter and set the 'fedora-review' flag to + 
Blocker bugs aren't being used for these reviews.

Could you re-assign and set the flags?
Comment 5 Fernando Nasser 2007-02-09 11:26:34 EST
1) W.r.t. Groups, please see the last message from 'spot' in the
fedora-packaging list:

"You can put whatever you would like in the Group field. Its not
regulated in Fedora whatsoever.
~spot"

That rpmlint warning is to be ignored as the Group use is actually deprecated
and will be replaced by a new mechanism with the RPM revamping project.

2) W.r.t. the javadoc code it is the current mechanism used at JPackage and
Fedora 6 for allowing multiple versions of a software and its documentation to
be installed.  I have unearthed upstream a proposal that would simplify this in
future JPackage releases, but current all Java paqckages that have -javadocs use
the above code.

Although I also want that code to be simplified, and I hope it will, it is not
using anything explicitly forbidden by the current Fedora Guidelines.
Comment 6 Thomas Fitzsimmons 2007-02-09 11:38:26 EST
(In reply to comment #5)
> 1) W.r.t. Groups, please see the last message from 'spot' in the
> fedora-packaging list:
> 
> "You can put whatever you would like in the Group field. Its not
> regulated in Fedora whatsoever.
> ~spot"
> 
> That rpmlint warning is to be ignored as the Group use is actually deprecated
> and will be replaced by a new mechanism with the RPM revamping project.

OK.

> 
> 2) W.r.t. the javadoc code it is the current mechanism used at JPackage and
> Fedora 6 for allowing multiple versions of a software and its documentation to
> be installed.  I have unearthed upstream a proposal that would simplify this in
> future JPackage releases, but current all Java paqckages that have -javadocs use
> the above code.
> 
> Although I also want that code to be simplified, and I hope it will, it is not
> using anything explicitly forbidden by the current Fedora Guidelines.

OK.

APPROVED.

Now we're supposed to leave this bug report open until the merged Fedora build
system comes online.
Comment 7 Thomas Fitzsimmons 2007-02-09 12:00:36 EST
(In reply to comment #6)

> Now we're supposed to leave this bug report open until the merged Fedora build
> system comes online.

I just talked with Warren.  The procedure is to build the package in Brew.  Then
when I've confirmed that the updated package has hit Rawhide, I'll close this
bug as "RAWHIDE".  So please go ahead and rebuild this package in Brew.

Note You need to log in before you can comment on or make changes to this bug.