Updated packages:
ftp://packman.iu-bremen.de/fedora/SRPMS/rt3.spec
ftp://packman.iu-bremen.de/fedora/SRPMS/rt3-3.4.4-4.src.rpm

Are all the deps in FE now ?
If there are still a few packages waiting for approval, please make the
associated bugs block this one.

(In reply to comment #2)
> Are all the deps in FE now ?
No. But all deps are in the request queue.

> If there are still a few packages waiting for approval, please make the
> associated bugs block this one.
I already did ;)

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

Silly me, was fooled by RedHat's bugzilla theming :)

(In reply to comment #2)
> Are all the deps in FE now ?
Now, they are ;) - Hint, hint!

$ rpmlint rt3-3.4.4-4.fc4.src.rpm
W: rt3 strange-permission rt3-filter-requires.sh 0755
W: rt3 strange-permission rt3-filter-provides.sh 0755

These are strange to me.  I would guess those are the proper permissions for
such files.  I'm assuming this is ignorable.

E: rt3 configure-without-libdir-spec

This can be ignored.  The configure script for rt3 doesn't take a libdir argument.

$ 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.  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.

E: rt3 non-readable /etc/rt3/RT_Config.pm 0640
E: rt3 non-readable /etc/rt3/RT_SiteConfig.pm 0640
E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data 0770
E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/cache 0770
E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/etc 0770
E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/obj 0770
E: rt3 non-standard-dir-perm /var/lib/rt3/session_data 0770
E: rt3 non-standard-gid /var/lib/rt3/mason_data apache
E: rt3 non-standard-gid /var/lib/rt3/mason_data/cache apache
E: rt3 non-standard-gid /var/lib/rt3/mason_data/etc apache
E: rt3 non-standard-gid /var/lib/rt3/mason_data/obj apache
E: rt3 non-standard-gid /var/lib/rt3/session_data apache
E: rt3 non-standard-uid /var/lib/rt3/mason_data apache
E: rt3 non-standard-uid /var/lib/rt3/mason_data/cache apache
E: rt3 non-standard-uid /var/lib/rt3/mason_data/etc apache
E: rt3 non-standard-uid /var/lib/rt3/mason_data/obj apache
E: rt3 non-standard-uid /var/lib/rt3/session_data apache

These are all ignorable.  They're set that way on purpose for security reasons.

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.

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?

An explicit requires is needed for perl(HTML::Mason).

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?

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.

(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.  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.

Does rt3 create these if they're not 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.

> 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.

> 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.

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).

(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 ...

(In reply to comment #8)
> > > 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.

The issue is nothing to do with networks; leaving the user there ensures that
any files left that are owned by the "rt3" user after deletion of the rt3
package are still owned by the "rt3" user if the package is subsequently
reinstalled. If the account is deleted on uninstall, the reinstallation may
result in a new rt3 user being created with a different UID to the original one

> > > 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.

I'm using httpd with SELinux without problems, albeit only serving static pages
and a few cgi scripts. I know though that more complex packages such as
squirrelmail can work with SELinux enabled too.

> > 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 ;)

What does the package do with the files/directories in /var/lib/rt3? Read?
Write? Execute?

(In reply to comment #9)
> (In reply to comment #8)
> > > > 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.
> 
> The issue is nothing to do with networks; leaving the user there ensures that
> any files left that are owned by the "rt3" user after deletion of the rt3
> package are still owned by the "rt3" user if the package is subsequently
> reinstalled. If the account is deleted on uninstall, the reinstallation may
> result in a new rt3 user being created with a different UID to the original
> one
There is no such issue, because the rt3 package does not leave any file being
owned by rt3 left around.
 
> I'm using httpd with SELinux without problems, albeit only serving static
> pages
> and a few cgi scripts. I know though that more complex packages such as
> squirrelmail can work with SELinux enabled too.
Does SELinux work for anything but trivial cases? IMO, no - It still leave much
to be desired and so far has failed to prove sustainability.

> What does the package do with the files/directories in /var/lib/rt3? Read?
> Write? Execute?
I am not sure about all scenarios, but in mine, /var/lib/rt3 (which IMO should
actually be /var/cache/rt3, but I had changed it to /var/lib to work around
SELinux deficits) is essentally only used by Mason. 
Both for writing and reading (It's a cache). I am not sure about executing.

(In reply to comment #10)
> > The issue is nothing to do with networks; leaving the user there ensures that
> > any files left that are owned by the "rt3" user after deletion of the rt3
> > package are still owned by the "rt3" user if the package is subsequently
> > reinstalled. If the account is deleted on uninstall, the reinstallation may
> > result in a new rt3 user being created with a different UID to the original
> > one
> There is no such issue, because the rt3 package does not leave any file being
> owned by rt3 left around.

No log files, cache files, etc.? That's OK then.

> > I'm using httpd with SELinux without problems, albeit only serving static
> > pages
> > and a few cgi scripts. I know though that more complex packages such as
> > squirrelmail can work with SELinux enabled too.
> Does SELinux work for anything but trivial cases? IMO, no - It still leave much
> to be desired and so far has failed to prove sustainability.
> 
> > What does the package do with the files/directories in /var/lib/rt3? Read?
> > Write? Execute?
> I am not sure about all scenarios, but in mine, /var/lib/rt3 (which IMO should
> actually be /var/cache/rt3, but I had changed it to /var/lib to work around
> SELinux deficits) is essentally only used by Mason. 
> Both for writing and reading (It's a cache). I am not sure about executing.

Try:
# chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3
and then try running in SELinux permissive mode to see what SELinux issues crop
up (check the output of "audit2allow -i /var/log/audit/audit.log") after running
rt3 for a short while.

Updated packages:
ftp://packman.iu-bremen.de/fedora/SRPMS/rt3.spec
ftp://packman.iu-bremen.de/fedora/SRPMS/rt3-3.4.4-5.src.rpm

(In reply to comment #11)
> Try:
> # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3

For what it's worth at this point, that is how I got RT3 to work with SELinux. 
If I find some time, I'll see about offering up a patch to the SELinux people.

(In reply to comment #8)
> > 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 was looking at the most recent package you had posted.  What I meant here is
that /var/cache/rt3 is a better choice than /var/lib/rt3; much the same as we
are using /var/cache/mason in the perl-HTML-Mason package.

I'll give -5 a look shortly.

(In reply to comment #13)
> (In reply to comment #11)
> > Try:
> > # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3
> 
> For what it's worth at this point, that is how I got RT3 to work with SELinux.

Is that *all* that was needed?
 
> If I find some time, I'll see about offering up a patch to the SELinux people.

The following lines added to file_contexts/program/apache.fc in the policy
sources should take care of both HTML::Mason and rt3

/var/cache/mason(/.*)?	system_u:object_r:httpd_cache_t
/var/cache/rt3(/.*)?	system_u:object_r:httpd_cache_t

I think we're all agreed that /var/cache/rt3 is a better option than
/var/lib/rt3, aren't we?

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> > > Try:
> > > # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3
> > 
> > For what it's worth at this point, that is how I got RT3 to work with SELinux.
> 
> Is that *all* that was needed?

Yes.

> I think we're all agreed that /var/cache/rt3 is a better option than
> /var/lib/rt3, aren't we?

I am.

(In reply to comment #14)

> The following lines added to file_contexts/program/apache.fc in the policy
> sources should take care of both HTML::Mason and rt3
> 
> /var/cache/mason(/.*)?	system_u:object_r:httpd_cache_t
> /var/cache/rt3(/.*)?	system_u:object_r:httpd_cache_t
How can this be achieved inside of the rt3-rpm?
 
> I think we're all agreed that /var/cache/rt3 is a better option than
> /var/lib/rt3, aren't we?
Yes, but unless somebody tells me how to achieve this inside of an rpm, without
having to modify on of the centralized SELinux packages I don't seem any
perspective to do so.

AFAIK, the current SELinux implementation doesn't allow this, except of (may-be)
running chcon inside of a %postin script directly.

You need to raise a bug against selinux-policy-targeted with the changes you
need to get rt3 to work.  I don't think there is a mechanism for individual
packages to update the selinux policy when they are installed.

or better to send an email to fedora-selinux-list. dan used to reply
to such request in a few days!

(In reply to comment #16)
> (In reply to comment #14)
> 
> > The following lines added to file_contexts/program/apache.fc in the policy
> > sources should take care of both HTML::Mason and rt3
> > 
> > /var/cache/mason(/.*)?	system_u:object_r:httpd_cache_t
> > /var/cache/rt3(/.*)?	system_u:object_r:httpd_cache_t
> How can this be achieved inside of the rt3-rpm?

They could be added to a file in /etc/selinux/targeted/contexts/files. However,
that would be the wrong approach. The right approach is to get the policy
changed upstream, by raising a bug on selinux-policy-targeted or mentioning the
issue on fedora-selinux-list, as mentioned in the previous two comments.

> > I think we're all agreed that /var/cache/rt3 is a better option than
> > /var/lib/rt3, aren't we?
> Yes, but unless somebody tells me how to achieve this inside of an rpm, without
> having to modify on of the centralized SELinux packages I don't seem any
> perspective to do so.
> 
> AFAIK, the current SELinux implementation doesn't allow this, except of (may-be)
> running chcon inside of a %postin script directly.

I'm happy to handle the SELinux bug report and get it fixed, but I need to make
sure that I'm getting the right directories fixed. There's no point getting the
context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used
by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the directories that
are going to be used?

BTW, I believe FC5 will have a more modular approach where tweaks to policy like
this *can* be handled within the package.

(In reply to comment #19)
> (In reply to comment #16)
> > (In reply to comment #14)
> > 
> > > The following lines added to file_contexts/program/apache.fc in the policy
> > > sources should take care of both HTML::Mason and rt3
> > > 
> > > /var/cache/mason(/.*)?	system_u:object_r:httpd_cache_t
> > > /var/cache/rt3(/.*)?	system_u:object_r:httpd_cache_t
> > How can this be achieved inside of the rt3-rpm?
> 
> They could be added to a file in /etc/selinux/targeted/contexts/files.
> However, that would be the wrong approach.
IMO, this approach is wrong without any doubt.

> The right approach is to get the policy
> changed upstream, by raising a bug on selinux-policy-targeted or mentioning the
> issue on fedora-selinux-list, as mentioned in the previous two comments.
I can't avoid to disagree, again.

> > > I think we're all agreed that /var/cache/rt3 is a better option than
> > > /var/lib/rt3, aren't we?
> > Yes, but unless somebody tells me how to achieve this inside of an rpm, without
> > having to modify on of the centralized SELinux packages I don't seem any
> > perspective to do so.
> > 
> > AFAIK, the current SELinux implementation doesn't allow this, except of (may-be)
> > running chcon inside of a %postin script directly.
> 
> I'm happy to handle the SELinux bug report and get it fixed, but I need
> to make sure that I'm getting the right directories fixed. There's no 
> point getting the
> context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used
> by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the 
> directories that are going to be used?
Yes, we want /var/cache/*, but are deadlocked and we can't switch to it, before
_SELinux_ has been changed.

> BTW, I believe FC5 will have a more modular approach where tweaks to 
> policy like this *can* be handled within the package.
Well, face it: SELinux suffers from the same design flaws as any other
centralized registry suffer from. IMO, this must be fixed ASAP or SELinux should
be discontinued.

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #16)
> > > (In reply to comment #14)
> > > > I think we're all agreed that /var/cache/rt3 is a better option than
> > > > /var/lib/rt3, aren't we?
> > > Yes, but unless somebody tells me how to achieve this inside of an rpm,
without
> > > having to modify on of the centralized SELinux packages I don't seem any
> > > perspective to do so.
> > > 
> > > AFAIK, the current SELinux implementation doesn't allow this, except of
(may-be)
> > > running chcon inside of a %postin script directly.
> > 
> > I'm happy to handle the SELinux bug report and get it fixed, but I need
> > to make sure that I'm getting the right directories fixed. There's no 
> > point getting the
> > context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used
> > by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the 
> > directories that are going to be used?
> Yes, we want /var/cache/*, but are deadlocked and we can't switch to it, before
> _SELinux_ has been changed.

I don't get this. In what way is using /var/lib/rt3 any less broken than using
/var/cache/rt3? With SELinux enabled, apache can write to neither.

In the meantime I shall raise the bug to get SELinux to support
/var/cache/{mason,rt3}

Another, hopefully the final version at:
ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3.spec
ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3-3.4.4-7.src.rpm

Most important change: This version uses /var/cache/rt3

The package still creates and owns /var/lib/rt3, and I notice that
/var/cache/rt3 is not owned.  I assume this is a typo in the %files section:

%dir %{_localstatedir}/lib/rt3
%attr(0770,apache,apache) %{RT3_CACHEDIR}/mason_data
%attr(0770,apache,apache) %{RT3_CACHEDIR}/session_data

Everything else looks good to me.  I'll give it about 24 hours before I set this
package to FE-ACCEPT, just in case anyone else has any input.

(In reply to comment #23)
> The package still creates and owns /var/lib/rt3,
Correct, because rt3 still uses it on occasion (cf. VarPath in RT.pm)
.. but there is another bug hiding this issue.

> and I notice that
> /var/cache/rt3 is not owned.
> I assume this is a typo in the %files section:
... and this is a bug ...

another iteration ...
ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3.spec
ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3-3.4.4-8.src.rpm

W: rt3 log-files-without-logrotate /var/log/rt3

I don't recall seeing this warning from rpmlint before, but it's there now. 
Maybe in a future release you can add a logrotate script.

Requires(post): /usr/bin/chcon

You can remove that, since you don't have a %post scriptlet.

APPROVED

(In reply to comment #25)
> W: rt3 log-files-without-logrotate /var/log/rt3
> 
> I don't recall seeing this warning from rpmlint before, but it's there now. 
> Maybe in a future release you can add a logrotate script.
Hmm, does rt3 generate logs for you?

> Requires(post): /usr/bin/chcon
> 
> You can remove that, since you don't have a %post scriptlet.
Done. Remnant from experiments with running chcon in %post scripts ;)

> APPROVED
Thanks 

Package Change Request
======================
Package Name: rt3
New Branches: EL-5
Updated Fedora CC: corsepiu xavierb mmahut
Updated EPEL Owners: xavierb mmahut
Updated EPEL CC: xavierb mmahut perl-sig

cvs done.

Package Change Request
======================
Package Name: rt3
InitialCC: perl-sig

Done.