[Bug 244346] Review Request: mailutils - Collection of GNU mail-related utilities

bugzilla at redhat.com bugzilla at redhat.com
Mon Jul 2 09:14:39 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: Review Request: mailutils - Collection of GNU mail-related utilities
Alias: mailutils-review


------- Additional Comments From lkundrak at redhat.com  2007-07-02 05:14 EST -------
(In reply to comment #11)

Patrice: Much thanks for your comments.

> You don't use some features, like
> libgsasl, guile, or emacs-mh. I think these should be shipped.

That sounds sane.  I will add those.

> I think it is bad to conflict with nmh. I think that
> you should use 
> --with-mh-bindir
> instead.

This was intentional.  If you look at the spec file, I already use
--with-mh-bindir=%{_bindir}, that overrides the default bin/mh location
of mh compatibility files.  The original reason was that rpmlint objected
having a subdirectory of bin.  I tend to agree with rpmlint -- I would not
call having binaries such weird places as subdirectories of bin a good
practice.  Moreover, I think there is no use of having both mh-s installed,
at a time, and conflicts are about the best and most standard way to deal
with situations such as this.

If not conflicting with nmh is important for you, and you insist on removing
the conflict, please either suggest an alternative resolution, or explain
where would you put the conflicting files and why.

> Some suggestions:
> * put the %post and friends before the %files section. There is no
>   reason, except that it is how all the other spec files are done
>   in fedora.

That's fair, I'll move that.

> * use wildcards for man pages and info pages in %files, like
> %{_infodir}/%{name}.info*
> %{_mandir}/man1/popauth.1*
> * don't use .gz in the install-info %preun, install-info is able to
>   figure out itself what compression it should use.

I was already wondering wheter manual pages are always gzipped.  Thus,
thanks for the explanation and be sure I'll change it.  I will probably have
to change it also in some other packages.

> * use 
> rm $RPM_BUILD_ROOT/%{_libdir}/%{name}/*.a
> instead of
> rm -f $RPM_BUILD_ROOT/%{_libdir}/%{name}/*.a
> that way build will break if something changed upstream.

Makes sense.  Will change that.

> * It seems to me that COPYING.LESSER should be in libs %doc
>   I also guess that devel subpackage is LGPL licensed.
>   I would also add COPYING in all the subpackages, since 
>   the doc subpackage may not be installed.
>   Alternatively you could have all packages depend on -doc
>   since it is tiny, and more like a common package that really
>   a doc package in my opinion.

I was thinking about the second option already, though it was for different
reasons and first one also makes sense.  I'll think for a while about this
and pick one of the solutions for the next revision of the package.

> * since this package is heavily split it would be nice, in my 
>   opinion, to try to have a similar layout than in other repos. 
>   I haven't really found other repos packaging mailutils, except
>   for alt linux, but I may have missed something. Maybe you could
>   use the split from the upstream specfile, as long as it makes sense
>   (no -dev subpackage, for example).

Will look at this later.

The revised packages with most of your suggestions incorporated will be
available either in today's evening (CET), or tomorrow.

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 package-review mailing list