Bug 244346 (mailutils-review)

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.

> 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

> %{_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?

Ruben, Bernard, thanks for your suggestions. They have been incorporated into
versions of files the links in description point to.

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.

Jason: I didn't increase the release intentionally, so I won't break the link
to srpm above.

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

Ralf: That's how the stupid and unjust world works.

Lubomir, that's not how Fedora works :-)
Please post a new link to the new srpm

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

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

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

Ping?

Lubomir, any update?

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.

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