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: lurker https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185535 ------- Additional Comments From jdennis@xxxxxxxxxx 2006-04-27 13:07 EST ------- Thank you for your careful review Jason and your thoughtful comments. I'm sorry I haven't responded sooner but I've got higher priority tasks than lurker packaging which have captured my attention. FYI, it was my plan to address the issue of a world writable database files by adding the owner and group to the configure script and passing it configure via %{mta_owner} and %{mta_group}. I do realized it is not strictly required to have this be available to configure because the RPM %files section can enforce the permissions but it is my belief that making this explicit is a win in terms of readability, upstream use, and those who may use configure outside the context of rpm. This is why these two variables appeared in the spec file, once configure could accept them they would be passed and set in the %files section. As for modern MTA configuration with respect to mail delivery I can attest as the previous maintainer for postfix, dovecot and mailman this is an area of endless user confusion :-( (Did you know postfix will deliver under the user id associated with the alias file the alias was found in?) Now throw into the mix per user procmail :-( It can be a mess and the source of lots of bug reports and list questions. I believe the best solution is to be absolutely explicit over the expected owner and group and thus will allevate 1 axis of confusion. As indicated above I will modify the spec file to make this absolutely explicit and locked down. With respect to requiring a C++ compiler, the code is C++ so that seemed necessary. It sounds like you may be more familar with this particular issue than I am so I will defer to you on this topic. You are correct, %{buildsubdir} is not guarenteed to exist, I'll fix that. I'm not sure I share your opinion that RPM_SOURCE_DIR should never be used. I appreciate that SOURCEn will always properly refer to it but I find use of SOURCEn to reduce readability and comprehenion of spec files. Whenever I encouter this use when reading a spec file I have to mentally expand the macro to understand what the spec file is doing, I find it much more comprensible if the operation is explicit. Hmm... I suppose the same argument could be used against %{httpdconffile} :-) At the time I packaged up lurker only the 1.3 version was available. Looks like the 2.0 release occurred shortly after I completed my work but before I got my review request in. I agree, 2.1 should be version in extras. I'll go back and do that, but it won't be immediate, I've got other tasks on my plate. I'm also going to have to figure out the differences between 1.3 and 2.x. -- 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@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review