Bug 235117 - Review Request: servletapi4 - Java servlet and JSP implementation classes
Summary: Review Request: servletapi4 - Java servlet and JSP implementation classes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arnaud Simon
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-03 20:03 UTC by Nuno Santos
Modified: 2013-09-12 22:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-04 15:09:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nuno Santos 2007-04-03 20:03:03 UTC
Spec URL: http://people.redhat.com/nsantos/fc7/servletapi4.spec
SRPM URL: http://people.redhat.com/nsantos/fc7/servletapi4-4.0.4-4jpp.src.rpm
Description: Java servlet and JSP implementation classes

Comment 1 Nuno Santos 2007-04-03 23:38:42 UTC
Updated specfile and srpm:

Spec URL: http://people.redhat.com/nsantos/fc7/servletapi4.spec
SRPM URL: http://people.redhat.com/nsantos/fc7/servletapi4-4.0.4-1.fc7.src.rpm


Comment 2 Arnaud Simon 2007-04-04 10:22:07 UTC
servletapi4-4.0.4-4jpp.src.rpm

Legend:
OK: passes criteria
NO: fails criteria (errors included between "--" markers)
NA: non applicable
??: unable to verify


MUST:
OK - package is named appropriately
OK - match upstream tarball or project name
OK - try to match previous incarnations in other distributions/packagers for
consistency

NO * specfile should be %{name}.spec

---> it is named: servletapi4.spec but it should be servletapi4-4.0.4-4jpp.spec

OK - non-numeric characters should only be used in Release (ie. cvs or
   something)
OK - for non-numerics (pre-release, CVS snapshots, etc.), see
   http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
OK - if case sensitivity is requested by upstream or you feel it should be
   not just lowercase, do so; otherwise, use all lower case for the name
OK - is it legal for Fedora to distribute this?
?? * OSI-approved
OK - not a kernel module
OK - not shareware
?? * is it covered by patents?
OK - it *probably* shouldn't be an emulator
OK - no binary firmware
OK - license field matches the actual license.
OK - license is open source-compatible.
OK - use acronyms for licences where common
?? * verify source and patches (md5sum matches upstream, know what the patches do)
 - if upstream doesn't release source drops, put *clear* instructions on
   how to generate the the source drop; ie. 
  # svn export blah/tag blah
  # tar cjf blah-version-src.tar.bz2 blah
OK - skim the summary and description for typos, etc.
NO * correct buildroot should be:
   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)


--> it is /jakarta-servletapi-4-src/


NA * if %{?dist} is used, it should be in that form (note the ? and %
locations)
NO * license text included in package and marked with %doc

--> included but not marked with %doc:


OK * keep old changelog entries; use judgement when removing (too old?
useless?)
NO * packages meets FHS (http://www.pathname.com/fhs/)

--> The rpm does not contain /lib (not sure this is normal) 

NO * rpmlint on <this package>.srpm gives no output
 - justify warnings if you think they shouldn't be there

--> Cannot install source packages.
    No packages were given for installation.

OK - changelog should be in one of these formats:

  * Fri Jun 23 2006 Jesse Keating <jkeating> - 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating> 0.6-4
  - And fix the link syntax.

  * Fri Jun 23 2006 Jesse Keating <jkeating>
  - 0.6-4
  - And fix the link syntax.

OK * Packager tag should not be used
OK * Vendor tag should not be used
OK * use License and not Copyright 
OK * Summary tag should not end in a period
NA * if possible, replace PreReq with Requires(pre) and/or Requires(post)
NO * specfile is legible
 - this is largely subjective; use your judgement

--> Those fields must be changed
Name:           %{name}
Version:        %{version}
Release:        %{release}.1%{?dist}

?? * package successfully compiles and builds on at least x86
?? * BuildRequires are proper
 - builds in mock will flush out problems here
 - the following packages don't need to be listed in BuildRequires:
   bash
   bzip2
   coreutils
   cpio
   diffutils
   fedora-release (and/or redhat-release)
   gcc
   gcc-c++
   gzip
   make
   patch
   perl
   redhat-rpm-config
   rpm-build
   sed
   tar
   unzip
   which
OK - summary should be a short and concise description of the package
OK - description expands upon summary (don't include installation
instructions)
OK - make sure lines are <= 80 characters
OK - specfile written in American English
OK - make a -doc sub-package if necessary
 - see
http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b
NA - packages including libraries should exclude static libraries if possible
OK - don't use rpath
NA * config files should usually be marked with %config(noreplace)
NA * GUI apps should contain .desktop files
NA * should the package contain a -devel sub-package?

?? * use macros appropriately and consistently
 - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS

OK * don't use %makeinstall
NA * locale data handling correct (find_lang)
 - if translations included, add BR: gettext and use %find_lang %{name} at the
   end of %install

?? * consider using cp -p to preserve timestamps

NA * split Requires(pre,post) into two separate lines
OK * package should probably not be relocatable
OK * package contains code
 - see http://fedoraproject.org/wiki/Packaging/Guidelines#CodeVsContent
 - in general, there should be no offensive content
OK * package should own all directories and files
OK * there should be no %files duplicates

?? * file permissions should be okay; %defattrs should be present

?? * %clean should be present

NA * %doc files should not affect runtime
NA * if it is a web apps, it should be in /usr/share/%{name} and *not* /var/www
?? * verify the final provides and requires of the binary RPMs
?? * run rpmlint on the binary RPMs

SHOULD:
NO * package should include license text in the package and mark it with %doc

--> included but not marked with %doc:


?? * package should build on i386
?? * package should build in mock

Comment 3 Nuno Santos 2007-04-04 15:50:59 UTC
> NO * specfile should be %{name}.spec
---> it is named: servletapi4.spec but it should be servletapi4-4.0.4-4jpp.spec

This is OK, %name refers just to the package name. No version/release should be
included in the specfile name.

> ?? * OSI-approved

It's an Apache license, so it's OK.

> ?? * is it covered by patents?

Distributed under Apache license, no explicit references to patents, so to the
best of our knowledge it's OK.

> ?? * verify source and patches (md5sum matches upstream, know what the patches 
> do)

To verify source/patches, follow instructions to obtain source and package it,
then run "md5sum" against the resulting tarfile, and compare to the tarfile
included in the srpm, they should match.
FWIW, md5sum on the tarfile in the srpm is:
91a4aeec8409a427c6a3b6d50924c15d  jakarta-servletapi-4-src.tar.gz

> NO * correct buildroot should be:
>   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
--> it is /jakarta-servletapi-4-src/

This is OK, buildroot in specfile is (see line 54):
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

> NA * if %{?dist} is used

dist is being used (see line 41):
Release:    %{release}%{?dist}

> NO * license text included in package and marked with %doc
--> included but not marked with %doc:

It's marked with %doc, see line 111:
%doc LICENSE README.txt

> NO * packages meets FHS (http://www.pathname.com/fhs/)
--> The rpm does not contain /lib (not sure this is normal)

It's OK.

> NO * rpmlint on <this package>.srpm gives no output
--> Cannot install source packages.

srpm doesn't need to be installed, just run rpmlint on it directly:
$ rpmlint  servletapi4-4.0.4-1.fc7.src.rpm
W: servletapi4 non-standard-group Internet/WWW/Dynamic Content
W: servletapi4 unversioned-explicit-obsoletes servlet4
W: servletapi4 unversioned-explicit-obsoletes servlet23
W: servletapi4 unversioned-explicit-provides servlet
W: servletapi4 unversioned-explicit-provides servlet4
W: servletapi4 unversioned-explicit-provides servlet23

These warnings are OK (other packages were approved with similar warnings).

> NO * specfile is legible
--> Those fields must be changed
> Name:           %{name}
> Version:        %{version}
> Release:        %{release}.1%{?dist}

Using the macros allows for name/version/release to be referred to later in the
specfile.

> ?? * package successfully compiles and builds on at least x86
> ?? * BuildRequires are proper

You'll have to setup mock and try to build the package there, to verify that it
builds.

> ?? * use macros appropriately and consistently

Usage is consistent to other packages that have been approved.

> ?? * consider using cp -p to preserve timestamps

It's used e.g. in line 98:
cp -pr build/docs/api/* $RPM_BUILD_ROOT%{_javadocdir}/%{name}

> ?? * file permissions should be okay; %defattrs should be present

defattrs present (see lines 110, 115):
%defattr(-,root,root)

> ?? * %clean should be present

Present (see lines 78/79):
%clean
rm -rf $RPM_BUILD_ROOT

> ?? * verify the final provides and requires of the binary RPMs
> ?? * run rpmlint on the binary RPMs
> ?? * package should build on i386
> ?? * package should build in mock

See comment above about setting up mock.

FWIW, here's the provides, requires, and rpmlint for the binary rpm:

$ rpm -qp servletapi4-4.0.4-1.fc7.noarch.rpm --provides
servlet  
servlet23  
servlet4  
servletapi4 = 0:4.0.4-1.fc7

$ rpm -qp servletapi4-4.0.4-1.fc7.noarch.rpm --requires
/bin/sh  
/bin/sh  
/usr/sbin/update-alternatives  
/usr/sbin/update-alternatives  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

$ rpmlint servletapi4-4.0.4-1.fc7.noarch.rpm
W: servletapi4 non-standard-group Internet/WWW/Dynamic Content


Comment 4 Rakesh Pandit 2008-09-03 14:32:59 UTC
@Nuno & @Arnaud

Are you folks interested in continuing?

This would be closed if no information is provided soon.

Comment 5 Nuno Santos 2008-09-04 15:09:30 UTC
I'm closing the ticket as it's not relevant anymore, thank you for the reminder.


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