[Bug 226495] Merge Review: tmpwatch

bugzilla at redhat.com bugzilla at redhat.com
Fri Jan 11 19:17:04 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Merge Review: tmpwatch


https://bugzilla.redhat.com/show_bug.cgi?id=226495


tibbs at math.uh.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbwillia at math.vt.edu, docs-
                   |                            |list at fedoralinks.org
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
             Status|NEW                         |ASSIGNED
               Flag|                            |fedora-review?




------- Additional Comments From tibbs at math.uh.edu  2008-01-11 14:17 EST -------
I took a further look and have a couple of additional issues.  To sumarize:

I there's really no upstream, please make a note of that in the spec. 
http://fedoraproject.org/wiki/Packaging/SourceURL
If it's hosted internally to Red Hat, please consider transferring it to some
externally visible site such as fedorahosted.org.

Parallel make: there's only one source file so there's really no point, but if
you're fixin things you might as well future-proof thins.

Then there's this rpmlint complaint:
%{_sysconfdir} is generally preferred to /etc.
  tmpwatch.x86_64: E: executable-marked-as-config-file /etc/cron.daily/tmpwatch
This one is interesting.  I'm guessing that this was marked as %config in the
past because someone was annoyed that a package update wiped out their changes.
 However:
  A shell script is a really poor configuration interface.
  If we end up having to protect an additional directory in /tmp from cleanup,
   there will be issues because we can't update that script.

Would it be at all possible to move the bits that people might want to configure
into a file in /etc/sysconfig?  It doesn't look like it should be difficult at all. 

The only licensing information I can see is in tmpwatch.c, which says only
"under the terms of the GPL".  Isn't Red Hat developed code supposed to be GPLv2
only?  I'm told it's corporate policy.

BuildRoot: is not correct; it needs to have at least %release, but would be
better if it were it were one of the recommended values.



Checklist:
? can't compare sources with upstream.
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written.
X should use %{_sysconfdir}
* summary is OK.
* description is OK.
X build root is improper.
? license field matches the actual license.
? not sure if the license is correct.
* BuildRequires are proper (none)
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* debuginfo package looks complete.
X rpmlint has valid complaints.
* final provides and requires are sane:
   config(tmpwatch) = 2.9.12-2
   tmpwatch = 2.9.12-2
  =
   /bin/sh
   config(tmpwatch) = 2.9.12-2
   psmisc

* %check is not present.
* no shared libraries are added to the regular linker search paths.
* neither creates nor owns any directories.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

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




More information about the Fedora-package-review mailing list