This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 244346 (mailutils-review)

Summary: Review Request: mailutils - Collection of GNU mail-related utilities
Product: [Fedora] Fedora Reporter: Lubomir Kundrak <lkundrak>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: debarshir, pertusus, ruben
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-20 14:01:41 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description Lubomir Kundrak 2007-06-15 04:14:02 EDT
Spec URL: http://people.redhat.com/lkundrak/SPECS/mailutils.spec
SRPM URL: http://people.redhat.com/lkundrak/SRPMS/mailutils-1.1-1.src.rpm
Description: Collection of GNU mail-related utilities

Mailutils is a GNU implementation of various mail-handling utilities.
This package offers basic Mailutils tools including SMTP and local
delivery agents.

mailutils-sieve - GNU implementation of Sieve mail filter language
mailutils-mailx - GNU implementation of MailX compatible mail user agent
mailutils-mh - GNU implementation of MH Message Handling system
mailutils-server - GNU implementations of IMAP, POP3 and mail notification servers
mailutils-devel - Files needed for building extensions to GNU Mailutils
mailutils-libs - Shared files for GNU Mailutils
mailutils-doc - Documentation for GNU Mailutils
Comment 1 Lubomir Kundrak 2007-06-15 04:23:39 EDT
E: mailutils setuid-binary /usr/libexec/mail.local root 04755
E: mailutils non-standard-executable-perm /usr/libexec/mail.local 04755
E: mailutils setgid-binary /usr/bin/dotlock mail 02755
E: mailutils non-standard-executable-perm /usr/bin/dotlock 02755

These obviously need to be setuid/setgid. This package is not dependent
on any other package, so one doesn't have to install setuid and setgid
binaries if he just wants to use other mailutils components.

W: mailutils-devel no-dependency-on mailutils

No reason to depend on it either. Shared files are in mailutils-libs.

W: mailutils no-documentation
W: mailutils-devel no-documentation
W: mailutils-libs no-documentation
W: mailutils-mh no-documentation
W: mailutils-sieve no-documentation

Documentation is in separate mailutils-doc package.

W: mailutils-libs one-line-command-in-%post /sbin/ldconfig
W: mailutils-libs one-line-command-in-%postun /sbin/ldconfig

Nothing wrong with that.
Comment 2 Ruben Kerkhof 2007-06-17 04:42:42 EDT
> W: mailutils-libs one-line-command-in-%post /sbin/ldconfig
> W: mailutils-libs one-line-command-in-%postun /sbin/ldconfig

You could use %post -p /sbin/ldconfig
Comment 3 Bernard Johnson 2007-06-18 03:09:40 EDT
> %{_datadir}/locale/*/LC_MESSAGES/%{name}.mo

I see you used %find_lang but you didn't get the %files section right. 
http://fedoraproject.org/wiki/Packaging/Guidelines#head-8c605ebf8330f6d505f384e671986fa99a8f72ee

You also probably want it somewhere other than -doc, I would guess the base package?
Comment 4 Lubomir Kundrak 2007-06-19 14:43:40 EDT
Ruben, Bernard, thanks for your suggestions. They have been incorporated into
versions of files the links in description point to.
Comment 5 Jason Tibbitts 2007-06-20 00:34:51 EDT
Is there an updated package?  Please remember to increase the release with each
change you make to the packagers so the reviewers can tell if they have the
correct version.
Comment 6 Lubomir Kundrak 2007-06-20 02:41:11 EDT
Jason: I didn't increase the release intentionally, so I won't break the link
to srpm above.
Comment 7 Ralf Corsepius 2007-06-20 03:02:16 EDT
(In reply to comment #6)
> Jason: I didn't increase the release intentionally, so I won't break the link
> to srpm above.
If you don't increase the release each time you update the package, reviewers
won't be able to distinguish their downloads from the status on a submitter's site.
Comment 8 Lubomir Kundrak 2007-06-20 16:35:39 EDT
Ralf: That's how the stupid and unjust world works.
Comment 9 Ruben Kerkhof 2007-06-20 16:47:01 EDT
Lubomir, that's not how Fedora works :-)
Please post a new link to the new srpm
Comment 10 Lubomir Kundrak 2007-06-21 07:49:04 EDT
Ruben, Jason ok, here are the new files. Ralf, please pardon may maybe a bit
harsh words, but could you please point me to a documentation link that would
say something about bumping revision numbers? I thought it is rather a matter
of personal preference, as I could not find relevant resources.

SPEC: http://people.redhat.com/lkundrak/SPECS/mailutils.spec
SRPM: http://people.redhat.com/lkundrak/SRPMS/mailutils-1.1-2.src.rpm
Comment 11 Patrice Dumas 2007-06-30 07:51:48 EDT
You don't use some features, like
libgsasl, guile, or emacs-mh. I think these should be shipped.

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

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.

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

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

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

* 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).
Comment 12 Lubomir Kundrak 2007-07-02 05:14:33 EDT
(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.
Comment 13 Debarshi Ray 2007-11-23 14:55:56 EST
Ping?
Comment 14 Ruben Kerkhof 2008-01-20 08:44:30 EST
Lubomir, any update?
Comment 15 Lubomir Kundrak 2008-01-20 14:01:41 EST
Sorry for not responding that long. I no longer need the package and probably
won't be able to give it love it deserves. I am WONTFIXing this report.

I'd be happy in case anyone else picks this up and finishes it.
Comment 16 Patrice Dumas 2008-09-29 08:56:58 EDT

*** This bug has been marked as a duplicate of bug 458180 ***