[Bug 537587] Review Request: dspam - bayesian filtering daemon, client, library and web ui

bugzilla at redhat.com bugzilla at redhat.com
Sun Jan 10 17:57:11 UTC 2010


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


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

--- Comment #50 from Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 2010-01-10 12:57:04 EST ---
Well,

(In reply to comment #49)
> - Created system user dspam via PackageUserRegistry instructions

- Instead please follow
  https://fedoraproject.org/wiki/Packaging/UsersAndGroups
  This is the current guidelines for adding user/group.

  - Note that uid 51 is already preserved on Fedora (see:
    /usr/share/doc/setup-2.8.13/uidgid )
    And usually you don't have to set this hardcodeded uid number.
  - We usually don't execute userdel/groupdel command during
    rpm transaction automatically because we think these commands
    are rather "dangerous" and these commands should be executed
    by sysadmin manually if needed.

  By the way %{dspam_home} macro is defined nowhere (perhaps you
  meant %{dspam_homedir}) (rpmlint is actually warning about this)

(In reply to comment #44)
> 1) I'm wondering how you find the non-owned directories. After you showed me
> the other ones I tried to make sure I had them all but couldn't seem to find a
> command that gives that output via google...

 - During package review I check unowned directories manually.
   Note:
   $ rpm -qlp dspam-XXXXXX.rpm | sort
   will give us hints for finding this.

> 2) The cron script for dspam requires that the user edit it to provide the path
> to the sql-script/backend they are using. So I would like it that upon upgrade,
> that file isn't overwritten however when marking it as %config(noreplace) I get
> rpmlint warnings about executable marked as config. Is there a proper way to
> have that file not be replaced by rpm on upgrades? 

  - Your comment seems to be saying that the sysadmin has to
    edit /etc/cron.daily/dspam and if so it is not desired.

    If this file needs some configuration these configuration
    should be written in the file under /etc/dspam (for example)
    like /etc/dspam/cron.conf and /etc/cron.daily/dspam should
    "source" that configuration file. Then /etc/dspam/cron.conf
    (for example) should be marked as %config(noreplace), while
    /etc/cron.daily/dspam should not have %config flag.

> I have one last issue I'm tracking down in the actual usage of the program as
> it should be placing logs in /var/log/dspam but they are being put in
> /var/lib/dspam at the moment even though the configure script is being told
> where so dspam should be behaving. Other than that dspam seems to be working
> well in my VMs and live boxes upgraded from a 3-4 year old self created rpm of
> 3.8.0. 
  - I hope that you or the upstream will find the cause

By the way I note that I have not tried to actually install dspam related
packages yet because of the left issues discussed before.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list