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: bugzilla - bug tracking tool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-14 10:42 EST ------- Note that I no longer have the attachment mentioned in the previous comment, so I cannot upload it again. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 00:58 EST ------- (In reply to comment #24) > Finally, this needs to live under /usr/share, not /var/www, which is a simple > edit of the first line plus the httpd.conf file. Will SELinux actually allow Apache to execute CGIs that live in /usr/share? Particularly ones that need to write to directories? ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 01:22 EST ------- I suggest you peruse the gallery2 review, which deals with this issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181599 My understanding is that selinux will allow apache to run things out of /usr/share as long as the appropriate selinux boolean is set. And if it didn't, we'd need to work with the selinux folks to get the necessary bits in. It's simply not permissible for us to put things in /var/www. Now, what does bugzilla need to write? I thought it was entirely database driven. Obviously it can't write to /usr/share, so we have to use another location. The gallery2 package uses a directory under /srv for this, but it does take selinux bits. The bug for that is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183140 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 01:37 EST ------- It has to write to the data/ directory and various subdirectories under that. The data directory is created by checksetup.pl. You can change where Bugzilla expects the data directory to be by editing the $datadir variable in Bugzilla/Config.pm. Why can't we put something in /var/www? It's where we normally put Bugzilla. Also note that Bugzilla requires *either* DBD::Pg or DBD::mysql, but it doesn't need both. I'm not sure how to handle that in RPM. The automatic deps will probably pick up both. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 11:37 EST ------- (In reply to comment #28) > Why can't we put something in /var/www? It's where we normally put Bugzilla. The naive answer is because the packaging guidelines indicate that it's not the proper place; see the end of http://fedoraproject.org/wiki/Packaging/Guidelines. The point is that once this is in Extras it's essentially a system component, and the system shouldn't install important pieces of itself into /var. > Also note that Bugzilla requires *either* DBD::Pg or DBD::mysql, but it > doesn't > need both. I'm not sure how to handle that in RPM. The automatic deps will > probably pick up both. RPM has no way to indicate this kind of either-or requirement; it's probably simpler to just install both unless we can somehow make two subpackages, bugzilla-postgres and bugzilla-mysql that provide bugzilla-db and pull in the necessary Perl modules for each specific database. I doubt it's worth it. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 19:00 EST ------- (In reply to comment #29) > RPM has no way to indicate this kind of either-or requirement; it's probably > simpler to just install both unless we can somehow make two subpackages, > bugzilla-postgres and bugzilla-mysql that provide bugzilla-db and pull in the > necessary Perl modules for each specific database. I doubt it's worth it. Okay. The problem is that those perl modules also pull in the databases themselves. So installing Bugzilla will now always install both postgresql and mysql. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 19:18 EST ------- Surely it only pulls in the client libraries? I can see no evidence that it will actually pull in the database servers; that would be nuts. Admittedly the mysql client libraries are a bit large (5MB) but that could be seen as a packaging bug since it contains the client command line interface as well. (perl-DBD-MySQL just wants libmysqlclient.) The Postgres client libs are only 500K. In any case, I'm not sure it would be acceptable to filter the perl-DBD dependencies and require that the end user know that they need to install one or the other. I guess it depends on whether or not then can be warned at setup time; if that's possible then it would be reasonable to do so. This isn't exactly and install-and-go package so I think it's acceptable to have them go back and pull in another package. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 19:22 EST ------- (In reply to comment #31) > This isn't > exactly and install-and-go package so I think it's acceptable to have them go > back and pull in another package. If they only pull in the client libraries, it's okay to have both of the perl modules be installed. It's true that running ./checksetup.pl will tell the user that they need to install the correct module, but it will give them CPAN instructions, and I think we'd prefer that they use RPMs. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 20:44 EST ------- We shouldn't fear patching things like checksetup to give the appropriate instructions, but in this case I think just requiring both is going to be our best bet. So what's left? We need to pick a location for the data directory; /srv/bugzilla makes the most sense to me. I need to get with the selinux gurus to see what's required there. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 23:34 EST ------- I would think that /var/bugzilla would make more sense, since that seems to fit the purpose of /var, yes? ------- Additional Comments From [EMAIL PROTECTED] 2006-06-10 23:48 EST ------- Well, that's a reasonable question. To address /var/bugzilla specifically, FHS forbids it: Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list. If it had to be in /var, /var/lib/bugzilla would be better. Here's what FHS has to say about /var and /srv: /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. /srv contains site-specific data which is served by this system. Seems to me like /srv is more appropriate. And in any case I'm just following gallery2's lead, which was packaged by the same person (John Berninger). I assume he'll chime in with why he chose that location and what he'd like to do about this package. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-11 00:01 EST ------- Okay. Very little of the data in data/ is technically "served" to the user--just certain graphics generated by graphviz. So /var/lib/bugzilla makes sense to me, but it's up to you guys in the end. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-11 00:18 EST ------- Ah, I had the impression that it held data such as uploaded attachments. If it's just transient data, why doesn't it just put it in /tmp? ------- Additional Comments From [EMAIL PROTECTED] 2006-06-11 00:29 EST ------- It's definitely not transient data. Bugzilla's per-server operating parameters are stored there, but they're written by a CGI. It also stores pre-compiled templates. It does store a few attachments, but most attachments are stored in the database (depending on user settings). Basically, it stores any file that the web server needs to write to or anything that Bugzilla generates dynamically. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-11 00:34 EST ------- If I may suggest, please don't stuff bugzilla in /srv: very few programs actually use it or /opt these days, and /var is an old and well-recognized place for data that gets a lot of disk access, and where the files experience churn and thus need frequent backup. /var/lib/bugzilla makes a certain amount of sense if /var/bugzilla is not easily negotiated for. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-12 07:52 EST ------- My vote would be for the app to go in /usr/share and the data to be in /var/lib/bugzilla (via a symlink if necessary). The only SELinux fiddling that should be necessary would I think to be to have /var/lib/bugzilla(/.*)? as httpd_var_lib_t. ------- Additional Comments From [EMAIL PROTECTED] 2006-06-12 12:40 EST ------- Now that I finally understand what bugzilla needs to write, I agree that /var/lib/bugzilla is indeed the proper place. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
