Bug 479594

I realize it's the upstream project name, but... wow, that name is going to cause a lot of search collisions.

The release history of 'email' goes back till 2001.  I guess that those guys definitely aren't going to change the name.

You should at least ask them and show them
https://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks#Use_of_common_namespace

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

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

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

Last week I sent again a message to upstream about the naming issue.  So fare no answer.

No answer from upstream...