Bug 479594 - Review Request: email - A command line SMTP client
Review Request: email - A command line SMTP client
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2009-01-11 16:38 EST by Fabian Affolter
Modified: 2009-12-17 15:50 EST (History)
5 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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

Description:
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:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1045764

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
https://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks#Use_of_common_namespace
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
ok
MUST: Fedora approved license
GPLv2+, ok
MUST: License field in the package spec file must match the actual license
ok
MUST: %doc %{license}
it is, ok
MUST: %doc files not important for runtime
ok
MUST: spec file in American English
ok
MUST: spec file legible
ok
MUST: souces must match upstream source
md5: cc51aeaa749d787915e8aa9bcd580c5d, ok
MUST: packages compiles succesfully
does, ok
MUST: build dependencies listed in BuildRequires
ok
MUST: locale handling with %find_lang
no locales, ok
MUST: shared libraries must call ldconfig in %post and %postun
ok
MUST: owns each directory it creates
ok
MUST: don't list a file more than once in %files listening
ok
MUST: %clean rm -rf %{buildroot}
ok
MUST: consistently using macros
partly ok, see further down
MUST: The package must contain code, or permissable content.
ok
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
ok
MUST: -devel must Requires: %{name} = %{version}-%{release}
ok
MUST: static libraries must be in a -static package
ok
MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'.
ok
MUST: .la libtool archive are forbitten
ok
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
ok
MUST: beginning of %install rm -rf %{buildroot}
ok
MUST: All filenames in rpm packages must be valid UTF-8.
ok

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

Note You need to log in before you can comment on or make changes to this bug.