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