Bug 479594

Summary: Review Request: email - A command line SMTP client
Product: [Fedora] Fedora Reporter: Fabian Affolter <mail>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cwickert, fedora-package-review, notting, rc040203, tomspur
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-17 15:50:17 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 201449    

Description Fabian Affolter 2009-01-11 16:38:12 EST
Spec URL: http://fab.fedorapeople.org/packages/SRPMS/email.spec
SRPM URL: http://fab.fedorapeople.org/packages/SRPMS/email-3.1.2-1.fc9.src.rpm

Project URL: http://www.cleancode.org/projects/email

mail is a program for the Unix environment that sends messages from the 
command line. It let you send email to remote SMTP servers.  Email makes
it simple to implement in cron jobs. You can pipe data into email and it
will accept it as your message which will bypass opening your editor, and
mail it properly. Also, you can tell email to stay quiet and never display
any output (except for errors) when operating.

Email boasts a lot of other qualities as well.

* Email supports SMTP Authentication.
* Email makes it possible to send to multiple recipients and also 
  CC and BCC multiple recipients.
* You can use an address book that is in an easy to format method.
* You are also able to send attachments using a swift flick on the 
  command line to specifying multiple files.
* Personalized signature file with dynamic options.

Koji scratch build:

rpmlint output:
[fab@laptop024 i386]$ rpmlint email*
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

[fab@laptop024 SRPMS]$ rpmlint email-3.1.2-1.fc9.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 1 Bill Nottingham 2009-01-12 15:04:23 EST
I realize it's the upstream project name, but... wow, that name is going to cause a lot of search collisions.
Comment 2 Fabian Affolter 2009-01-27 08:06:44 EST
The release history of 'email' goes back till 2001.  I guess that those guys definitely aren't going to change the name.
Comment 3 Christoph Wickert 2009-02-14 14:47:31 EST
You should at least ask them and show them
Comment 4 Thomas Spura 2009-08-06 16:10:52 EDT
I'm no packager, reviewing this as learning guidelines by reviewing others

MUST: rpmlint
already posted, ok
MUST: spec file is %{name}.spec
MUST: Fedora approved license
GPLv2+, ok
MUST: License field in the package spec file must match the actual license
MUST: %doc %{license}
it is, ok
MUST: %doc files not important for runtime
MUST: spec file in American English
MUST: spec file legible
MUST: souces must match upstream source
md5: cc51aeaa749d787915e8aa9bcd580c5d, ok
MUST: packages compiles succesfully
does, ok
MUST: build dependencies listed in BuildRequires
MUST: locale handling with %find_lang
no locales, ok
MUST: shared libraries must call ldconfig in %post and %postun
MUST: owns each directory it creates
MUST: don't list a file more than once in %files listening
MUST: %clean rm -rf %{buildroot}
MUST: consistently using macros
partly ok, see further down
MUST: The package must contain code, or permissable content.
MUST: large documentation files must go in a -doc subpackage
not large, ok
MUST: header files must be in a -devel package
no header, ok
MUST: libraries with ending .so must be in -devel package
MUST: -devel must Requires: %{name} = %{version}-%{release}
MUST: static libraries must be in a -static package
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'.
MUST: .la libtool archive are forbitten
MUST: Packages containing GUI applications must include a %{name}.desktop file
      and desktop-file-install in %install;
      no %{name}.desktop -> reason explained in %{name}.spec
no gui, ok
MUST: Packages must not own files or directories already owned by other packages
MUST: beginning of %install rm -rf %{buildroot}
MUST: All filenames in rpm packages must be valid UTF-8.

MUST: permissions properly set
probably ok, as just copying, *but*:

The Makefile installs the programm in the wrong place!
See prefix = /usr/local
and not prefix = /usr
As a test with make install DESTDIR=tmp INSTALL="install -p" is wrong, but within the spec, anything behaves correctly (->prefix = /usr). Don't see why.
But ok ;-)

The name email should be ok for me. There already exists email2trac, deletemail and archivemail. Furthermore email reflects, what the program does. This kind of common namespace should be avoided, but here not possible. How could it renamed? 'send' or whatever? yum search mail is much bigger than yum search email atm…

No blocker, I'd approve this, if I could ;-)
(After the explanation of my the makefile problem, of course^^)
Comment 5 Ralf Corsepius 2009-08-07 03:21:58 EDT
(In reply to comment #4)

> As a test with make install DESTDIR=tmp INSTALL="install -p" is wrong, but
> within the spec, anything behaves correctly (->prefix = /usr). Don't see why.

Probably one or more of these:
a) DESTDIR must be an absolute directory. A relative dir (DESTDIR=tmp) will never work.
b) You didn't pass the options, rpmbuild'ing applies, to configure.

> The name email should be ok for me.
Not for me - I consider this package's name, the binary's name and the config-files's names to be a short-sighted (silly?) upstream decision.

> How could it renamed?
* After the author (Dean Jones): djmail, deansmail
* After the author's site (cleancode.org): cleanmail, cleancode.org-mail
... Bonzo?

If this package was fully supporting autoconf, --program-prefix could be used as escape - Unfortunately this package doesn't.

> No blocker, I'd approve this, if I could ;-)
> (After the explanation of my the makefile problem, of course^^)  

Other issues:

1) The package doesn't honor $INSTALL => Besides the fact that
make "INSTALL=install -p" is almost always meaningless, 
it is completely non-functional in this particular case.

2) The package tarball contains autom4te.caches. Shiping only adds bloat to a tarball and is hardly of any use.

3) The package seems to support ssl/tls, but is compiled without it 
(c.f. configure --help, check --with-ssl)

4) The sources contains excerpts from RFCs.
c.f. files: RFC821, rfc3156-openpgp.txt, quoted-printable.rfc
Normally RFCs are distributable for free when "being properly credited".

I am not sure if this consideration applies to the files as being shipped with this package.
Comment 6 Christoph Wickert 2009-08-07 05:06:21 EDT
(In reply to comment #4)

> The name email should be ok for me. There already exists email2trac, deletemail
> and archivemail.

Thomas, the package name is not (really) a problem, but the names of the installed files, especially %{_bindir}/%{name}. If every package chooses such silly names, we would have five different %{_bindir}/%{name} and all these packages would conflict.
Comment 7 Fabian Affolter 2009-11-18 10:22:40 EST
Last week I sent again a message to upstream about the naming issue.  So fare no answer.
Comment 8 Fabian Affolter 2009-12-17 15:50:17 EST
No answer from upstream...