[Bug 225708] Merge Review: dovecot

[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: Merge Review: dovecot


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


tjanouse at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED
               Flag|needinfo?(tjanouse at redhat.co|
                   |m)                          |




------- Additional Comments From tjanouse at redhat.com  2007-03-02 10:01 EST -------
Hi Jef,
thanks for your review, I applied your diff and commited, just changed the
section removing .la/.a files to use find instead. My comments follow:


(In reply to comment #1)
> ? MUST: Every binary RPM package which stores shared library files (not just
> symlinks) in any of the dynamic linker's default paths, must call ldconfig in
> %post and %postun. If the package has multiple subpackages with libraries, each
> subpackage should also have a %post/%postun section that calls /sbin/ldconfig.
>   Comment:  shared libs exist in /usr/lib/dovecot but they appear to be simple
> plugins for dovecot's own runtime use and not meant for linking.  if this is the
> case, then no corrections need to be made. Please confirm that the items in
> /usr/lib/dovecot are not meant to be dynamically linkable libraries.

I confirm that.

> E: dovecot configure-without-libdir-spec
> ?????  I am not sure what rpmlint is trying to tell us here.

This is probably a rpmlint bug, the libdir is passed by %configure itself.

> E: dovecot non-readable /etc/pki/dovecot/certs/dovecot.pem 0600
> E: dovecot non-standard-uid /var/lib/dovecot dovecot
> E: dovecot non-standard-gid /var/lib/dovecot dovecot
> E: dovecot non-standard-dir-perm /var/lib/dovecot 0750
> E: dovecot non-standard-gid /var/run/dovecot/login dovecot
> E: dovecot non-standard-dir-perm /var/run/dovecot/login 0750
> E: dovecot non-readable /etc/pki/dovecot/private/dovecot.pem 0600
> .... all of these rpmlint errors appear to be bogus to me. Please confirm that
> the permissions and ownership are as intended for these.

Yes, they are.

> W: dovecot dangerous-command-in-%pre rm
> W: dovecot dangerous-command-in-%post mv
> W: dovecot dangerous-command-in-%preun userdel
> ....  I think these warnings are bogus. Though you may want to look back over 
>       the use of the rm and mv commands to see if they are still needed.
>       I think I understand why the restart_flag logic is present.  
>       But I do not understand why the ssl cert manipulation logic block is in  
>       %post.  All the file location testing and conditional use of mv. What
>       cases trigger the mv commands? Is this logic meant for now EOL'd fedora 
>       and rhl releases?

Yeah, the certificate paths used to be different, this block moves them to new
location.


(In reply to comment #4)
> If there is no -devel package, does that stop someone from being able to build
> something like http://wiki.dovecot.org/LDA/Sieve?highlight=%28dovecot-sieve%29
> against it? I know that Sieve will not build the way dovecot is currently
> packaged, because the Sieve program needs to be able to find a file called
> dovecot-config in the "compiled Dovecot sources". I do not know what the correct
> way to handle this but I ask that you take my comments into consideration, in
> case someone would like to use Dovecot-Sive with this package.

I didn't find any easy way to make dovecot-sieve compile against packaged
version. It just wants access to the dovecot build dir. I might create a -devel
package in the future as upstream added an option to install headers, but the
location of things is probably still not ok. Regarding dovecot-sieve, we'll
probably build that from the same source package.

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