[Bug 169247] Review request: rt3 - Request tracker 3

[bugzilla at redhat.com]

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

Summary: Review request: rt3 - Request tracker 3


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





------- Additional Comments From rc040203 at freenet.de  2005-10-13 05:30 EST -------
(In reply to comment #6)
> [Many rpmlint complaints, probably ignorable]

Yes, rpmlint is facing its limitations and deficits at many places with this rpm.

> W: rt3 non-conffile-in-etc /etc/rt3/acl.Informix
> W: rt3 non-conffile-in-etc /etc/rt3/acl.mysql
> W: rt3 non-conffile-in-etc /etc/rt3/acl.Oracle
> W: rt3 non-conffile-in-etc /etc/rt3/acl.Pg
> W: rt3 non-conffile-in-etc /etc/rt3/acl.Sybase
> W: rt3 non-conffile-in-etc /etc/rt3/initialdata
> W: rt3 non-conffile-in-etc /etc/rt3/schema.Informix
> W: rt3 non-conffile-in-etc /etc/rt3/schema.mysql
> W: rt3 non-conffile-in-etc /etc/rt3/schema.Oracle
> W: rt3 non-conffile-in-etc /etc/rt3/schema.Pg
> W: rt3 non-conffile-in-etc /etc/rt3/schema.SQLite
> W: rt3 non-conffile-in-etc /etc/rt3/schema.Sybase
> 
> True, these aren't configuration files, but rather initialization files.
> Maybe a better place for them would be /usr/share/rt3?
May-be, may-be it's rpmlint enforcing non-existing standards. I am inclined to
think the latter. All the FHS says is "The /etc hierarchy contains configuration
files", it doesn't say "configuration files only" nor does it prohibit "initial
data files".

For now I don't want to move them to avoid further surgery on the package
configuration nor do I see any need to do so.

> An explicit requires is needed for perl(HTML::Mason).
Right, this is missing.

> I don't like that /usr/sbin/webmux.pl has mode +x, since it's meant to be
> sourced and doesn't actually do anything when run.  I think it would be better
> somewhere like /usr/lib/rt3, but I don't know how much that change would affect
> the RT install.
> 
> Would /var/lib/rt3 be better as /var/cache/rt3?
Hmm? Are you looking at an older rpm? My latest version (3.4.4-4) uses /var/lib/rt3.

> I ran into SELinux issues when starting httpd.  Maybe a README.SELinux
> mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux
> settings.
> 
> It took some tinkering to get running (installing the proper DBD and
> initializing the database).  The existing README section on initializing the
> database isn't appropriate for an RPM-based install.  For its target audience, I
> don't think it's very difficult.  Maybe just add README.Fedora to point users to
> /etc/rt3.
> 
> I didn't know what to do with RT once I got it running and didn't have much luck
> getting rt-setup-database to work, but I'm going to chalk that up to user error.
>  I did get a login page with RT installed on my local httpd server, so I'm going
> to go ahead and say the package does work as intended.
I need to try setting it up once again. It's been a while since I did (mysql
based config) and have it running since ;)


(In reply to comment #7)
> (In reply to comment #6)
> > $ rpmlint rt3-3.4.4-4.fc4.noarch.rpm | sort
> > E: rt3 dir-or-file-in-usr-local /usr/local/etc/rt3
> > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3
> > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/html
> > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/lib
> > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/po
> > 
> > Why are directories being %ghosted in /usr/local?  I see these directories being
> > configured in the Fedora layout, and I'm inferring from it that these are used
> > for user-generated content.
Yes, these are for user provided stuff. These dirs are being added to PATH
variables all over the place (grep -R LOCAL_ * inside of the source tree for
details)

> >  If that's the case, I don't really see a problem
> > with it, but it is odd to see an package owning anything in /usr/local.
Well, actually many package use the standardized dirs below /usr/local. They
only don't have to make this explicit, because the "filesystem" rpm already owns
them.

> Does rt3 create these if they're not present?
AFAICT, no. It just uses them, whether or not these dirs are present.

> I guess ghosting directories here
> is OK if the directories won't get removed if they're not empty, which I would
> think (but am not sure) would be rpm's behaviour here.

Just try and you'll see what happens (FC4):
# mkdir /usr/local/etc/rt3
# touch /usr/local/etc/rt3/foo
# rpm -e rt3
# ls /usr/local/etc/rt3/
foo
=> The directory will be removed from the rpmdb. IIRC, older rpms issued a
"directory not empty" or similar warning on similar sitations.

> > W: rt3 dangerous-command-in-%postun userdel
> > 
> > I'll leave this one alone.  The package creates the user in %pre, it's only
> > right that the user is removed when no longer needed, I suppose.
> 
> See
> https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg00271.html
> for why users and groups shouldn't be removed when a package is uninstalled.
Then you probably know my attitude on this topic. 

The rt3 user is a local system account (!) and is not meant to be used across
networks. Also, the rt3 package has all files being own by the rt3 user under
its control.

> > I ran into SELinux issues when starting httpd.
And so do I. I have _never_ been able to use httpd without switching SELinux off
for it. With having switched SELinux off for httpd I am able to run rt3 without
any problems.

>>  Maybe a README.SELinux
> > mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux
> > settings.

> If you know what the contexts should be for this directory and its contents, you
> could raise the issue on fedora-selinux-list or in bugzilla for one of the
> policy packages and hopefully get the right contexts set by default in an
> updated version of the policy packages. That has to be better than manually
> setting contexts (which would need fixing again after a relabel).
... some SELinux geek will have to implement this ;)

Updated package to be released soon ...

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