[Bug 225708] Merge Review: dovecot
bugzilla at redhat.com
bugzilla at redhat.com
Mon Feb 26 07:15:11 UTC 2007
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
------- Additional Comments From jspaleta at gmail.com 2007-02-26 02:15 EST -------
Executive Summary:
Okay this package needs some work. I've tried to incorporate as many of the
important changes as I could into an updated specfile. I will attach a diff of
my spec against the spec in fedora core cvs for your to look over. Additionally
you can find my spec and the srpm built from it at.
Please take a close look at the specfile diff. If there are any changes that you
have an issue with, we will need to discuss them.
I'll probably have other minor specfile cleanup suggestions on a second pass
through the specfile after we work through the important changes.
The very detailed review follows below.
Legend:
GOOD: + BAD: -
Not Applicable: N/A
Still in Progress or questinable: ?
+ MUST: The package is named according to the Package Naming Guidelines.
+ MUST: The spec file name is good
+ MUST: The package is licensed with approved licenses
+ MUST: The License field in the package spec file matches the most relevant
actual license.
Comment: parts of the upstream code are lcensed under the MIT license, but it
is probably best to list the LGPL here alone, since by the nature of the
interaction of the licenses the LGPL applies to everything in the upstream source.
+ MUST: The spec file is written in a close approximation of American English.
+ MUST: The spec file for the package is legible.
+ MUST: The package must successfully compile and build into binary rpms on at
least one supported architecture.
see
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/dovecot-1.0-3.rc22.fc7.src.rpm/result/
+ MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of Packaging Guidelines; inclusion of
those as BuildRequires is optional. Apply common sense.
+ MUST: A package must not contain any duplicate files in the %files listing.
+ MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
+ MUST: Each package must consistently use macros, as described in the macros
section of Packaging Guidelines.
+ MUST: The package must contain code, or permissable content. This is described
in detail in the code vs. content section of Packaging Guidelines.
+ MUST: Packages must not own files or directories already owned by other packages.
Comment: This appears to be true
- MUST: rpmlint output with comments inline below.
- MUST: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.
Need to include COPYING COPYING.MIT and COPYING.LGPL in the docs. Fixed in
updated spec diff
- MUST: The sources used to build the package must match the upstream source, as
provided in the spec URL. Reviewers should use md5sum for this task.
The SOURCE0 url was inadequate, fixed in the supplied specfile diff.
md5sum check passes:
upstraam release: d5bd3ce8ba7ca2ee9f563fe63a1f700a dovecot-1.0.rc22.tar.gz
included source: d5bd3ce8ba7ca2ee9f563fe63a1f700a dovecot-1.0.rc22.tar.gz
- MUST: A package must own all directories that it creates.
comment: /etc/pki/dovecot not owned, fixed in provided specfile diff
- MUST: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.
comment: mkcert.sh is being used in %post. This is not good and it breaks the
rule concerning running properly if docs are not present. mkcert should be
moved to libexec and used from there. Fixed in the provided spec.
- MUST: Header files or static libraries must be in a -devel package.
comment: Need to remove .a files or create a -devel package for them with a
justification as to why the static libs are needed. The best thing to do is to
remove the .la and .a files all together. This is done in the specfile diff
provided.
- MUST: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
Comment: removed in the provided specfile diff.
? 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.
? MUST: Permissions on files must be set properly.
comment: see rpmlint comments below
? MUST: The package must meet the Packaging Guidelines.
N/A MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
N/A MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in ExcludeArch.
N/A package is not designed to be relocatable
N/A MUST: No Large documentation files or -doc subpackage.
N/A no pkgconfig(.pc) files in payload
N/A MUST: If a package contains library files with a suffix (e.g.
libfoo.so.1.1), then library files that end in .so (without suffix) must go in a
-devel package.
N/A MUST: no devel subpackage In the vast majority of cases, devel packages must
require the base package using a fully versioned dependency: Requires: %{name} =
%{version}-%{release}
N/A Package does not contain GUI application no need for a %{name}.desktop file
RPMLINT COMMENTS INLINE
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/dovecot-1.0-3.rc22.fc7.src.rpm/result/rpmlint.log
rpmlint on dovecot-1.0-3.rc22.fc7.src.rpm
W: dovecot strange-permission migrate-users 0755
W: dovecot strange-permission migrate-folders 0755
W: dovecot strange-permission dovecot.init 0755
W: dovecot strange-permission perfect_maildir.pl 0755
...These permissions appear to be okay to me.
W: dovecot prereq-use openssl >= 0.9.7f-4, /sbin/chkconfig, /usr/sbin/useradd
... Requires fixed in provided specfile diff. prereq is no longer valid. See the
PackagingGuidelines for more details
E: dovecot configure-without-libdir-spec
????? I am not sure what rpmlint is trying to tell us here.
E: dovecot use-of-RPM_SOURCE_DIR
.... The other option would be to use the appropriate SOURCE# macros for each
source file. Changed in the specfile diff provided.
W: dovecot macro-in-%changelog _datadir
W: dovecot macro-in-%changelog post
.... Editted in spec diff
W: dovecot mixed-use-of-spaces-and-tabs (spaces: line 82, tab: line 84)
.... fixed in spec diff
W: dovecot patch-not-applied Patch104: dovecot-1.0.beta2-lib64.patch
.... commented out in spec diff
rpmlint on dovecot-1.0-3.rc22.fc7.i386.rpm
W: dovecot conffile-without-noreplace-flag /etc/pam.d/dovecot
W: dovecot conffile-without-noreplace-flag /etc/rc.d/init.d/dovecot
.... I think the pam.d config needs to be noreplace to perserve local admin
changes if they are made. Updated in the specfile diff.
E: dovecot non-standard-gid /var/run/dovecot dovecot
.... this is fine.
E: dovecot executable-marked-as-config-file /etc/rc.d/init.d/dovecot
.... this is standard for initscripts
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.
E: dovecot non-standard-gid /usr/share/doc/dovecot-1.0/examples/mkcert.sh dovecot
E: dovecot non-readable /usr/share/doc/dovecot-1.0/examples/mkcert.sh 0750
E: dovecot non-standard-executable-perm
/usr/share/doc/dovecot-1.0/examples/mkcert.sh 0750
.... I think these are valid errors, if mkcert.sh is really meant to be a doc
item. But its being used in post so it needs to be moved out of the doc area.
Fixed in provided spec diff.
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib20_convert_plugin.a
W: dovecot devel-file-in-non-devel-package
/usr/lib/dovecot/imap/lib11_imap_quota_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/imap/lib20_zlib_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib01_acl_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib11_trash_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib10_quota_plugin.a
W: dovecot devel-file-in-non-devel-package
/usr/lib/dovecot/lib02_lazy_expunge_plugin.a
W: dovecot devel-file-in-non-devel-package /usr/lib/dovecot/lib20_mail_log_plugin.a
.... the .a files are removed in specfile diff
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?
--
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.
More information about the Fedora-package-review
mailing list