Bug 435829 - Review Request: tomcat6 - Apache Servlet/JSP Engine, RI for Servlet 2.5/JSP 2.1 API
Review Request: tomcat6 - Apache Servlet/JSP Engine, RI for Servlet 2.5/JSP ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Permaine Cheung
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-03 20:42 EST by David Walluck
Modified: 2010-07-07 21:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-11 20:00:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pcheung: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description David Walluck 2008-03-03 20:42:03 EST
Spec URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6.spec
SRPM URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6-6.0.16-1jpp.1.fc9.src.rpm
Description: 
Tomcat is the servlet container that is used in the official Reference
Implementation for the Java Servlet and JavaServer Pages technologies.
The Java Servlet and JavaServer Pages specifications are developed by
Sun under the Java Community Process.

Tomcat is developed in an open and participatory environment and
released under the Apache Software License version 2.0. Tomcat is intended
to be a collaboration of the best-of-breed developers from around the world.
Notes:
The tomcat6 package is being provided as an update to the tomcat5 package in accordance with the mailing list thread here <http://www.redhat.com/archives/fedora-packaging/2007-December/msg00005.html>. We would like to keep the tomcat5 package around for now as it is parallel installable with tomcat6 and existing packages in Fedora depend on it.
Comment 1 Jason Corley 2008-03-04 20:24:08 EST
Going through the changelog since I didn't catch up with you on IRC.

- use %%{_initrddir} macro instead of %%{_sysconfdir}/init.d (rhbz #153187)

incorrect given that LSB currently mandates /etc/init.d
(http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html)

- fix incorrect initscript output (rhbz #380921)

portability issue, can't be done for JPackage

- update initscript (rhbz #247077)

confused by this one, we've had LSB comments for quite a while... incorrect number?

- add logrotate support

you don't want to do this, logging in tomcat 6.x (and 5.5.x) is done via log4j
and already has log rotation, you'll just end up with a nice full directory of
0kb .XX.gz files (which is why it was removed from 6.x in the first place)

- remove file-based requires

same portability comment as above

- fix strange-permission

which one? there's a bunch (I'm guessing) and they generally have reasons...
Comment 2 David Walluck 2008-03-04 22:52:47 EST
- use %%{_initrddir} macro instead of %%{_sysconfdir}/init.d (rhbz #153187)

I would think that the definition of %{_initrddir} in Fedora may be incompatible
with the LSB, but that this should not affect its use within spec files in
accordance with bug #153187 comment #2.

- update initscript (rhbz #247077)

This is in accordance with http://fedoraproject.org/wiki/FCNewInit/Initscripts
which required implementing different return values and some additional arguments.

- remove file-based requires

One issue with regard to JPackage is that Fedora ships update-alternatives in
the chkconfig package but does not provide update-alternatives as a virtual. The
others are probably safe. I don't think that file-based requires violate Fedora
policy as long as they are located in certain directories, but I preferred to
change them.

- fix strange-permission

rpmlint wants all sources to be shipped in the SRPM to be mode 0644, and then
for example, the initscript may be made executable in the %files list instead.
This does not refer to the uid/gid and modes necessary to run as the tomcat user
which is normal for servers such as these.
Comment 3 David Walluck 2008-03-04 23:04:02 EST
Some other known issues are:

- use of /srv
- initscript does not use standard start/stop functions (e.g., `daemon')
- upstream shell scripts do not find Java according to JPackage standard
Comment 5 Permaine Cheung 2008-03-18 10:57:16 EDT
I'll take this.
Comment 6 Permaine Cheung 2008-03-18 11:08:57 EDT
Please fix item(s) mared by X:
MUST:
* package is named appropriately
 - match upstream tarball or project name
 - try to match previous incarnations in other distributions/packagers for
consistency
 - specfile should be %{name}.spec
 - non-numeric characters should only be used in Release (ie. cvs or
   something)
 - for non-numerics (pre-release, CVS snapshots, etc.), see
   http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
 - 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
* is it legal for Fedora to distribute this?
 - OSI-approved
 - not a kernel module
 - not shareware
 - is it covered by patents?
 - it *probably* shouldn't be an emulator
 - no binary firmware
* license field matches the actual license.
* license is open source-compatible.
 - use acronyms for licences where common
* specfile name matches %{name}
* 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
* skim the summary and description for typos, etc.
* correct buildroot
 - should be:
   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
We're keeping the buildroot as NVR as per discussed in the meeting with Fedora
and JPackage folks.
* if %{?dist} is used, it should be in that form (note the ? and %
locations)
* license text included in package and marked with %doc
* keep old changelog entries; use judgement when removing (too old?
useless?)
* packages meets FHS (http://www.pathname.com/fhs/)
* rpmlint on <this package>.srpm gives no output
 - justify warnings if you think they shouldn't be there
* changelog should be in one of these formats:

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

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

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

* Packager tag should not be used
* Vendor tag should not be used
* Distribution tag should not be used
* use License and not Copyright 
* Summary tag should not end in a period
* if possible, replace PreReq with Requires(pre) and/or Requires(post)
X specfile is legible
 - in tomcat6-6.0.conf, JAVA_HOME is set to /usr/lib/jvm/java-icedtea, shouldn't
it be set to /usr/lib/jvm/java and set alternatives to set icedtea to be the jvm?
 - in tomcat6-6.0.init, should a check to see if the file
/etc/rc.d/init.d/functions exists before sourcing it?
 - should icedtea be listed as Requires as well?
 - is jpackage-utils a Requires as well?
 - is this the correct link for FHS 2.3:
http://www.pathname.com/fhs/pub/fhs-2.3.html
* package successfully compiles and builds on at least x86
X 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
X sed doesn't need to be listed as a BR.
* summary should be a short and concise description of the package
* description expands upon summary (don't include installation
instructions)
* make sure lines are <= 80 characters
* specfile written in American English
* make a -doc sub-package if necessary
 - see
  
http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b
* packages including libraries should exclude static libraries if possible
* don't use rpath
* config files should usually be marked with %config(noreplace)
* GUI apps should contain .desktop files
* 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
* don't use %makeinstall
* install section must begin with rm -rf $RPM_BUILD_ROOT or %{buildroot}
* 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
* split Requires(pre,post) into two separate lines
* package should probably not be relocatable
* package contains code
 - see http://fedoraproject.org/wiki/Packaging/Guidelines#CodeVsContent
 - in general, there should be no offensive content
* package should own all directories and files
* there should be no %files duplicates
* file permissions should be okay; %defattrs should be present
* %clean should be present
* %doc files should not affect runtime
* 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:
* package should include license text in the package and mark it with %doc
* package should build on i386
X package should build in mock
I'm getting:
Cannot find build req  java-devel-icedtea >= 0:1.5.0. Exiting.
ending

I'll continue reviewing once I can build it in mock
Comment 7 David Walluck 2008-03-18 11:40:36 EDT
* packages meets FHS (http://www.pathname.com/fhs/)

I changed from /srv in the upstream JPackage spec as I don't think Fedora allows
this, but I can't find any reference right now.

X specfile is legible
 - in tomcat6-6.0.conf, JAVA_HOME is set to /usr/lib/jvm/java-icedtea, shouldn't
it be set to /usr/lib/jvm/java and set alternatives to set icedtea to be the jvm?

I think I should get rid of the specific icedtea reference. But fnasser
mentioned it had to be built and run on icedtea. However, I don't think we
should exclude GCJ, but it hasn't be tested by me on there.

X BuildRequires are proper

Will build again in mock.

X sed doesn't need to be listed as a BR.

OK

X package should build in mock

Package built in mock for me when I posted it. This is due to the recent change
to java-1.6.0-openjdk. Removing the specific requirement on icedtea will fix this.
Comment 8 David Walluck 2008-03-18 14:13:50 EDT
SRPM URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6-6.0.16-1jpp.4.fc9.src.rpm

It builds for me in mock with `BuildRequires: java-devel >= 1.6.0'. If we leave
it unversioned, gcj is pulled in and it does not currently build with gcj.

I commented out JAVA_HOME in tomcat6.conf, it should now use the default one.
Comment 9 Permaine Cheung 2008-03-18 18:16:53 EDT
Running rpmlint on the binary rpms built in mock:
rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-6.0.16-1jpp.4.fc9.noarch.rpm
tomcat6.noarch: W: dangling-symlink /usr/share/tomcat6/lib /usr/share/java/tomcat6
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/lib
/usr/share/java/tomcat6
tomcat6.noarch: E: non-standard-gid /var/log/tomcat6 tomcat
tomcat6.noarch: E: non-standard-dir-perm /var/log/tomcat6 0775
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/work
/var/cache/tomcat6
tomcat6.noarch: E: non-standard-gid /etc/tomcat6/tomcat-users.xml tomcat
tomcat6.noarch: E: non-readable /etc/tomcat6/tomcat-users.xml 0660
tomcat6.noarch: E: non-standard-gid /var/lib/tomcat6/webapps tomcat
tomcat6.noarch: E: non-standard-dir-perm /var/lib/tomcat6/webapps 0775
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/conf /etc/tomcat6
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/temp
/var/tmp/tomcat6
tomcat6.noarch: E: non-standard-gid /var/tmp/tomcat6 tomcat
tomcat6.noarch: E: dir-or-file-in-tmp /var/tmp/tomcat6
tomcat6.noarch: E: non-standard-dir-perm /var/tmp/tomcat6 0775
tomcat6.noarch: E: non-standard-gid /var/cache/tomcat6 tomcat
tomcat6.noarch: E: non-standard-dir-perm /var/cache/tomcat6 0775
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/logs
/var/log/tomcat6
tomcat6.noarch: E: non-standard-gid /etc/tomcat6/Catalina/localhost tomcat
tomcat6.noarch: E: non-standard-dir-perm /etc/tomcat6/Catalina/localhost 0775
tomcat6.noarch: W: symlink-should-be-relative /usr/share/tomcat6/webapps
/var/lib/tomcat6/webapps
tomcat6.noarch: W: dangerous-command-in-%preun rm
tomcat6.noarch: E: use-tmp-in-%preun
tomcat6.noarch: W: incoherent-subsys /etc/rc.d/init.d/tomcat6 ${NAME}
tomcat6.noarch: W: incoherent-subsys /etc/rc.d/init.d/tomcat6 ${NAME}
tomcat6.noarch: W: incoherent-subsys /etc/rc.d/init.d/tomcat6 ${NAME}
tomcat6.noarch: W: incoherent-subsys /etc/rc.d/init.d/tomcat6 ${NAME}

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-admin-webapps-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-admin-webapps.noarch: W: no-documentation

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-docs-webapp-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-docs-webapp.noarch: W: no-documentation

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-javadoc-6.0.16-1jpp.4.fc9.noarch.rpm



rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-jsp-2.1-api-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-jsp-2.1-api.noarch: W: no-documentation

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-lib-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-lib.noarch: W: no-documentation
tomcat6-lib.noarch: W: dangling-relative-symlink
/usr/share/java/tomcat6/tomcat6-servlet-2.5-api-6.0.16.jar
../tomcat6-servlet-2.5-api-6.0.16.jar
tomcat6-lib.noarch: W: dangling-relative-symlink
/usr/share/java/tomcat6/tomcat6-jsp-2.1-api-6.0.16.jar
../tomcat6-jsp-2.1-api-6.0.16.jar
tomcat6-lib.noarch: W: dangerous-command-in-%preun rm

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-servlet-2.5-api-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-servlet-2.5-api.noarch: W: no-documentation

rpmlint
/var/lib/mock/fedora-development-i386/result/tomcat6-webapps-6.0.16-1jpp.4.fc9.noarch.rpm

tomcat6-webapps.noarch: W: no-documentation

I'll continue to look into the subpackages and scripts.
Comment 10 David Walluck 2008-03-19 01:04:14 EDT
Anything of note in the rpmlint output?

I already fixed what I thought was important. However, I changed the Group tag
to please rpmlint, and it seems we can be using the same groups as JPackage, so
perhaps I should change them back.

Is there any way to easily fix symlink-should-be-relative? 

Concerning the scripts, the main dtomcat6 script might be able to make more use
of the java-functions script. Also, in tomcat5 there was a tomcat5 script and a
dtomcat5 script, but in the tomcat6 package there is only dtomcat6 even though I
think the name tomcat6 might make more sense to people.
Comment 11 Permaine Cheung 2008-03-19 14:41:09 EDT
We should try to fix the errors if possible, otherwise, please explain why it
has to be done that way. 

You can leave the Group tag as it was orginially.

I don't see any problem renaming the dtomcat6 script to just tomcat6.

The tomcat5-jsp-2.0-api has virtual provides for jsp, does the
tomcat6-jsp-2.1-api package need that as well?

The servlet-api package in tomcat5 also virtual provides servlet, servlet24,
servlet5 and servletapi5, do we need similar provides for the one in tomcat6?
Comment 12 David Walluck 2008-03-19 18:28:33 EDT
I posted something like this earlier, but I guess I hit the wrong button.

For rpmlint, symlink-should-be-relative is a warning, not an error. The only
errors have to do with file permissions (normal for a daemon) and the use of
/var/tmp/tomcat6 which is a link from /usr/share/tomcat6/temp, so it appears to
be necessary. I don't know of any other package that owns a directory under
/var/tmp, though.

I will change the Group tags back.

I need to think more about the tomcat6 script. What is the use case? Is it
always called from the initscript with the proper user set? Should the
command-line options be getopt style or just stick to the same options as in
dtomcat6? I would like to keep dtomcat6 for compatibility and I guess have
tomcat6 call to dtomcat6 (which is how it worked in tomcat5).

I think you are right about the Provides. Another issue is that there is a
servletapi6 package in JPackage 5.0/devel, whereas tomcat6 is in JPackage 5.0
(main). I think that tomcat6 should Provides/Obsoletes servletapi6 so this looks
like an upstream JPackage bug.
Comment 13 Permaine Cheung 2008-03-20 08:49:17 EDT
I believe the proper use is with the initscript.
Also, if it has to be build and run with openjdk, we need to BR and R
java-openjdk, don't we?
There's a war in tomcat6-docs-webapp-6.0.16-1jpp.4.fc9.noarch.rpm -
/var/lib/tomcat6/webapps/docs/appdev/sample/sample.war, should that be exploded?
There's no jars inside this war, just the following:
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/mypackage/
WEB-INF/lib/
images/
WEB-INF/classes/mypackage/Hello.class
WEB-INF/web.xml
hello.jsp
images/tomcat.gif
index.html
Comment 14 David Walluck 2008-03-20 09:41:59 EDT
I thought we were already against the requirement on icedtea and forcing
JAVA_HOME, so the same applies for openjdk. I already BuildRequires: java >=
1.6.0. I suppose we could require 1.6.0 as the exact version. There are a few
ways to do this.

I am not sure that webapp is actually used since it's not directly under
webapps, but I will check.
Comment 15 Permaine Cheung 2008-03-20 10:19:51 EDT
Sorry for the confusion, I meant that we should have BuildRequires and Requires,
not setting JAVA_HOME. I think that if it should build and run with openjdk, we
should specify java-openjdk as the BuildRequires and Requires. What do you think?

You're right, it's not under webapps and it looks like just a sample war that
the user can deploy themselves, plus it doesn't have any jars in it. The main
reason for the exploded one is for symlinks in the jar, so I think this one is ok.
Comment 16 David Walluck 2008-03-20 16:57:31 EDT
Is (Build)Requires: java >= 1.6.0 enough? If we use 1.5.0, then gcj (which
doesn't work) could satisfy this---unless BuildConflicts will work.
Comment 17 Permaine Cheung 2008-03-20 17:12:34 EDT
Ok, lets just keep the java>= 1.6.0.
Comment 18 David Walluck 2008-03-20 18:09:17 EDT
This sounds like a general problem that should be addressed by the Fedora Java
packaging guidelines.

For one thing, requiring openjdk specifically sounds too explicit. If someone
has the Sun or IBM JDK 1.5.0 or greater, this should also technically be able to
satify the requirement. (I know this is Fedora, but I am assuming that one goal
is interoperablitiy with JPackage and other JDK vendors).

On the other hand, even requiring a specific version at runtime (Requires: java
>= 1.6.0) isn't enough to ensure that the user won't try to run with GCJ at some
point.
Comment 19 David Walluck 2008-03-24 17:29:12 EDT
SRPM URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6-6.0.16-1jpp.6.fc9.src.rpm

I decided to package the sample webapp. This actually did contain binary code in
the war (which wasn't being removed). I also found Thumbs.db files from Windows
in the images directories, so I removed these as well.

I added Requires: java >= 0:1.6.0 as we discussed.

I would like to take another look at the startup script, but I think I have
covered all of the other issues so far.
Comment 20 Jason Corley 2008-03-30 12:59:09 EDT
It's probably best to avoid versionless Provides for jsp and servlet (think of
the issues we've had with the JDK from Sun and the -compat packages).  Better
would be something like:

Provides: jsp <= %{jspspec}
Provides: servlet <= %{servletspec}
Comment 21 Permaine Cheung 2008-04-02 11:27:18 EDT
There are a few unversioned porvides/obseletes:
tomcat6.src:129: W: unversioned-explicit-provides jsp
tomcat6.src:130: W: unversioned-explicit-provides jsp21
tomcat6.src:155: W: unversioned-explicit-obsoletes servletapi6
tomcat6.src:156: W: unversioned-explicit-provides servletapi6
tomcat6.src:157: W: unversioned-explicit-provides servlet
tomcat6.src:158: W: unversioned-explicit-provides servlet6
tomcat6.src:159: W: unversioned-explicit-provides servlet25

license should be ASL 2.0, and rpmlint will stop complaining

coreutils doesn't need to be listed as BuildRequires.

Shouldn't the content in the docs-webapp package be marked as %doc?

in tomcat6-6.0.wrapper, /usr/share/java-utils/java-functions is sourced without
a check if it exists.

With regards to the issues that you mentioned earlier:
- use of /srv - this is fixed, right?
- initscript does not use standard start/stop functions (e.g., `daemon') - what
was the reason that we do not use the standard start/stop functions?
- upstream shell scripts do not find Java according to JPackage standard - are
these fixed?
Comment 22 David Walluck 2008-04-02 12:09:08 EDT
Jason Corley suggested in comment #20 doing something with the unversioned jsp
and servlet provides. Are these backwards compatible or not? Otherwise, why even
keep them at all. I am not sure that we can version the other provides since the
version is the tomcat version, which would not be the case with some other API
provider, presumably.

The license was ASL 2.0 in the past rpms. I changed it back to what JPackage
had. This seems correct according to the Fedora wiki. I think rpmlint is just
wrong here.

I will fix the coreutils BuildRequires.

I don't think we can mark the doc webapp as doc. We can't mark any content
needed to run as doc. Docs must be 100% optional.

We usually check for the existence of /usr/share/java-utils/java-functions
first. I can do this, but why? We already Requires: jpackage-utils, so it must
exist.

/srv is fixed

The other two are more complicated. I find java using java-functions, but I left
most of the script the same as JPackage. It is probably fine, but it could use
java-functions more.

About the initscript, I changed most of what I could. The reason we can't
necessarily use the built-in killproc function is that: (1) we had to call
"stop" to stop the server---but Jason Brittain told me that tomcat should do the
right thing when it receives a KILL signal (I haven't verified this) (2) if the
PID file is missing, it will try to find the tomcat6 process (clearly wrong,
it's some java process), and I don't know how the PID file will go missing in
practice.

For startup, maybe we could use the daemon function? Right now it's hardcoded to
call runuser if it exists and su if not.

The main issue is that the initscript is not using the standard functions making
the code large and difficult to maintain. For example, the initscript output was
broken because it was overriding some built-in functions from
/etc/init.d/functions. Jason Corley told me that most of this was due to
incompatibilities in the Fedora and RHEL functions, but I would rather write the
script in the standard way and deal with this problem if/when it arises for us.
Comment 23 Permaine Cheung 2008-04-02 14:44:54 EDT
(In reply to comment #22)
> Jason Corley suggested in comment #20 doing something with the unversioned jsp
> and servlet provides. Are these backwards compatible or not? Otherwise, why even
> keep them at all. I am not sure that we can version the other provides since the
> version is the tomcat version, which would not be the case with some other API
> provider, presumably.
> 
It seems Jason Corley suggested versioning of provides/obsoletes, unversioned
will match any versioned provides/obsoletes. For the ones that are the tomcat
version, should the version be the same as the tomcat version then?

> The license was ASL 2.0 in the past rpms. I changed it back to what JPackage
> had. This seems correct according to the Fedora wiki. I think rpmlint is just
> wrong here.
> 
I think rpmlint has been updated with the new license format.

> I will fix the coreutils BuildRequires.
> 
Great!
> I don't think we can mark the doc webapp as doc. We can't mark any content
> needed to run as doc. Docs must be 100% optional.
> 
OK.
> We usually check for the existence of /usr/share/java-utils/java-functions
> first. I can do this, but why? We already Requires: jpackage-utils, so it must
> exist.
> 
I saw it in the other scripts, and this one is missing, so I thought that should
be here too.

> /srv is fixed
> 
> The other two are more complicated. I find java using java-functions, but I left
> most of the script the same as JPackage. It is probably fine, but it could use
> java-functions more.
> 
> About the initscript, I changed most of what I could. The reason we can't
> necessarily use the built-in killproc function is that: (1) we had to call
> "stop" to stop the server---but Jason Brittain told me that tomcat should do the
> right thing when it receives a KILL signal (I haven't verified this) (2) if the
> PID file is missing, it will try to find the tomcat6 process (clearly wrong,
> it's some java process), and I don't know how the PID file will go missing in
> practice.
> 
> For startup, maybe we could use the daemon function? Right now it's hardcoded to
> call runuser if it exists and su if not.
> 
> The main issue is that the initscript is not using the standard functions making
> the code large and difficult to maintain. For example, the initscript output was
> broken because it was overriding some built-in functions from
> /etc/init.d/functions. Jason Corley told me that most of this was due to
> incompatibilities in the Fedora and RHEL functions, but I would rather write the
> script in the standard way and deal with this problem if/when it arises for us.
> 
Sounds good.
Comment 24 David Walluck 2008-04-02 15:12:58 EDT
For the versioned provides, Jason Corley suggested using the spec version. To
use the tomcat version doesn't make sense (what about other vendors'
implementation of the spec?). I think, if anything, we should use the spec/API
version. He also didn't suggest versioning the provides that already have a
number in them (e.g., `6' or `25'), although 6 is the tomcat major version. But
I am not clear what to do to resolve this issue now.

The rpmlint config has Apache License, Apache Software License, and ASL 2.0, but
not Apache Software License 2.0, but I think this should be allowed based on the
wiki.

The initscript changes will need testing. However, none of the default functions
seem to work properly if the process name is not unique. In our case `java'
could identify any number of processes, not just tomcat processes. For example,
I implemented a workaround to the status function based on JPackage. The
difference is that I try to use the built-in function where possible. The
killproc function has a similar problem.
Comment 25 David Walluck 2008-04-02 17:27:11 EDT
I checked for BuildRequires: coreutils and it's not there. There is a
Requires(preun) on it for the lib package since it calls rm in %preun lib.
Comment 26 Permaine Cheung 2008-04-03 07:58:46 EDT
I see what you mean now, adding the number for the provides that doesn't have a
number in it. I think adding the spec numbers in those cases is the best that we
can do for now.

If you run rpmlint -I invalid-license, you'll see the list of valid licenses,
and ASL 2.0 is one of them.

Hmm... so the built-in functions as they are won't work with java in general
then.  Looking at the status function (in 1jpp.6.fc9 rpm), if we have tomcat5
running at the same time, will that work properly if we do a pgrep with those
parameters?

The coreutils as a Requires(preun) is fine, thanks for checking that.
Comment 27 David Walluck 2008-04-03 14:14:40 EDT
I think that adding `Provides: servlet = servlet_spec_version' should be OK. I
don't think we need to use <= since we only have to satisfy unversioned requires
in practice.

Re-reading the wiki, it seems that only the short name is allowed for licenses.
This means we have to diverge from JPackage here.

It does appear that the pgrep will *not* work properly in the presence of
multiple tomcat instances being run by the tomcat user. In my current
initscript, I changed this from the default behavior to be a fallback only, but
I think that it's likely dangerous to have it.
Comment 28 Permaine Cheung 2008-04-03 15:13:26 EDT
I agree that it's likely dangerous to have that pgrep in there, can you think of
a better way to do it?
Comment 29 David Walluck 2008-04-03 15:18:39 EDT
The best way is the default way where we record the PID and then use that directly.

The fallback method is supposed to be used in the case of a missing PID file (I
am not sure when this would even happen).

The default function may suffer from a similar problem (see killproc and
__pids_pidof in /etc/init.d/functions).
Comment 30 David Walluck 2008-04-04 11:00:45 EDT
I versioned the servlet and jsp Provides with their respective spec versions.

Originally, I had servlet-%{servletspec}-api Obsoletes/Provides servletapi6.
However, servletapi6 contains *both* servletapi and jspapi and it also turns out
that these packages don't even conflict sicne they have a `6' in their name.

The servletapi6 package has these provides:

Provides:       servlet
Provides:       servlet6
Provides:       servlet25
Comment 31 David Walluck 2008-04-07 11:49:30 EDT
SRPM URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6-6.0.16-1jpp.7.fc9.src.rpm

More on the changes:

The initscript should be fixed to only call pgrep if the PID file doesn't exist.
If the PID file exists, the built-in status function can be used.

I have moved d%{name} to %{name} and created a symlink for d%{name}. In the
tomcat5 package, the scripts are different files, and %{name} launches d%{name}
with the tomcat user. Note that these scripts are in %{_sbindir} which should be
more correct according to FHS, whereas the tomcat5 package has them in %{_bindir).
Comment 32 Permaine Cheung 2008-04-07 15:32:21 EDT
Looks good.
APPROVED
Comment 33 David Walluck 2008-04-07 16:59:22 EDT
New Package CVS Request
=======================
Package Name: tomcat6
Short Description: Apache Servlet/JSP Engine, RI for Servlet 2.5/JSP 2.1 API
Owners: dwalluck
Branches: F-9
InitialCC:
Cvsextras Commits: yes
Comment 34 Kevin Fenzi 2008-04-07 18:04:56 EDT
cvs done.
Comment 35 David Walluck 2008-04-11 20:00:58 EDT
The package tomcat6-6.0.16-1jpp.7.fc9 is currently in rawhide (F9 branch).
Comment 36 James Laska 2010-07-07 08:03:00 EDT
Package Change Request
======================
Package Name: tomcat6
New Branches: EL-5
Owners: akurtakov, dknox, dwalluck
Comment 37 Kevin Fenzi 2010-07-07 21:13:52 EDT
CVS done (by process-cvs-requests.py).

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