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.
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...
- 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.
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
SRPM URL: http://dwalluck.fedorapeople.org/tomcat6/tomcat6-6.0.16-1jpp.2.fc9.src.rpm
I'll take this.
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> - 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. * 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
* 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.
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.
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.
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.
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?
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.
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
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.
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.
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.
Ok, lets just keep the java>= 1.6.0.
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.
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.
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}
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?
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.
(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.
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.
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.
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.
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.
I agree that it's likely dangerous to have that pgrep in there, can you think of a better way to do it?
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).
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
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).
Looks good. APPROVED
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
cvs done.
The package tomcat6-6.0.16-1jpp.7.fc9 is currently in rawhide (F9 branch).
Package Change Request ====================== Package Name: tomcat6 New Branches: EL-5 Owners: akurtakov, dknox, dwalluck
CVS done (by process-cvs-requests.py).