Bug 208064

Forgot to mention, rpmlint complains about library-without-ldconfig-postun but
none of the files listed are actually in a directory that ldconfig would load,
nor are they used by anything other than courier itself, which knows the proper
place to look.

As I maintain a local version (and have done for a while so I'll probably
compare along the way) I'll pick this one up for review.

The specfile does deviate from what FE expects, so cleaning it up completely is
indeed a challenge. :-)

I have noticed a couple of things:

* Unless you're patching the init file, it defaults to enabled on boot.
* There's a few BR's there that are redundant (gcc-c++, libtool)
* The Epoch references in subpackage Requires: are probably not needed, 
* Have you considered for the userdb databases? (configure --with-db=db) - I
just don't trust the default gdbm... 

Oh, for comparison:

http://www.enlartenment.com/packages/fedora/5/SRPMS/courier-authlib-0.58-1.fc5.mf.src.rpm

I left the init and userdb stuff as the default because that's what the upstream
spec does (plus, the init stuff makes sense to me, and I've never had issues
with gdbm stuff).  Like I said, I don't want to maintain a separate spec (too
much other stuff going on; I don't think I could do a good job at it), but am
willing to clean up the upstream spec occasionally (which Sam accepted) to keep
it as close to fedora's needs as possible.

I can fix the BR and epoch stuff, but it's not worth it if I end up having to
maintain an entire separate spec from Sam's.

question -- if you maintain your own already, why not submit to FE?

Michael, any reply?

I'll have another closer look later today.

Sam pushed out a rash of releases over the new year break, including 0.59. It's
functionally identical (at least from our POV) so I'm happy to keep reviewing
the existing package as-is. It might be a courtesy to users to import it or a
later version once approved of course.

If you're concerned about ongoing maintenance - it's not too difficult (an
evolving process, few specs are perfect on first import) and I'll put my hand up
for co-maintainership if desired.

(As to why I've not submitted mine - folks have beaten me to this and maildrop,
and the courier-imap spec will eat your brain. It will take a herculean effort
to get it to the point where it satisfies FE requirements while still working as
Sam intended.)

OK, I've had a closer look at this. There's not much left to fix up, don't let
the length of the review fool you :-). Fix these and I can check and approve
this without a hassle.

The following is all OK:

* RPM name is OK
* Source courier-authlib-0.58.tar.bz2 is the same as upstream
* Builds in mock (i386 / x86_64, FC5 and FC6)
* Runs OK.

NEEDSWORK:
* Lose the courier_release / distribution detection routines, they're not needed
for Fedora purposes and (IMO) just clutter the specfile. Disttags alone should
do the desired job.
* BuildRequires: gcc-c++ should not be included                                 
  (wiki: PackagingGuidelines#Exceptions)    
* Requires: %{name} = %{version}-%{release} would be preferred to having an
explicit "0" Epoch in the subpackage reqs.
* Update to 0.59, which works quite well.

RPMLINT:

E: courier-authlib non-standard-executable-perm /etc/rc.d/init.d/courier-authlib
0555

* Hack this to 755/750 in %files to shut it up. 

E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libcourierauth.so.0.0.0
E: courier-authlib library-without-ldconfig-postun
/usr/lib/courier-authlib/libcourierauth.so.0.0.0

* These are dlopen()ed IIRC, so this can actually be ignored.

E: courier-authlib non-standard-executable-perm
/usr/libexec/courier-authlib/authmigrate 0555
E: courier-authlib non-standard-executable-perm
/usr/libexec/courier-authlib/sysconftool 0555

* Change this to 755 in the spec (It's there in lines 5 and 6 after %install)
and this goes away too (what's Sam thinking here??)

E: courier-authlib non-readable /var/spool/authdaemon/pid.lock 0600
E: courier-authlib non-readable /etc/authlib/authmysqlrc.dist 0660
E: courier-authlib non-readable /etc/authlib/authldaprc.dist 0660
E: courier-authlib non-readable /etc/authlib/authdaemonrc.dist 0660
E: courier-authlib non-readable /etc/authlib/authpgsqlrc.dist 0660

* Ignore these (running RPMlint as non-privileged user)

W: courier-authlib non-conffile-in-etc /etc/authlib/authmysqlrc.dist
W: courier-authlib non-conffile-in-etc /etc/authlib/authldaprc.dist
W: courier-authlib non-conffile-in-etc /etc/authlib/authdaemonrc.dist
W: courier-authlib non-conffile-in-etc /etc/authlib/authpgsqlrc.dist
55

* I'd ignore these too (rpmlint doesn't seem to recognise these for some reason)

E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libcourierauthcommon.so.0.0.0
E: courier-authlib library-without-ldconfig-postun
/usr/lib/courier-authlib/libcourierauthcommon.so.0.0.0
E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libauthcustom.so.0.0.0
E: courier-authlib library-without-ldconfig-postun 
/usr/lib/courier-authlib/libauthcustom.so.0.0.0
E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libcourierauthsasl.so.0.0.0
E: courier-authlib library-without-ldconfig-postun
/usr/lib/courier-authlib/libcourierauthsasl.so.0.0.0
E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libcourierauthsaslclient.so.0.0.0
E: courier-authlib library-without-ldconfig-postun
/usr/lib/courier-authlib/libcourierauthsaslclient.so.0.0.0
E: courier-authlib postin-without-ldconfig
/usr/lib/courier-authlib/libauthpam.so.0.0.0
E: courier-authlib library-without-ldconfig-postun
/usr/lib/courier-authlib/libauthpam.so.0.0.0

* dlopen()ed again I believe, don't worry too much.

E: courier-authlib non-standard-dir-perm /var/spool/authdaemon 0750

* I actually have this as 755 on my server, as I'm often running maildrop /
imapd as the delivering user (not daemon/bin/root/mail etc.). YMMV, but my
solution keeps rpmlint happy and allows any calling user to access the
world-writable socket it contains.

W: courier-authlib service-default-enabled /etc/rc.d/init.d/courier-authlib
E: courier-authlib no-status-entry /etc/rc.d/init.d/courier-authlib

Patch the included init file for this one (Swap "2345" for "-" for the first
issue and steal the stanza from rpmdevtools' template.init for the status.

Please note the current status of this bug.

On 16-Jan-2007 version 0.59.1 of courier-authlib was released.

I will close this bug as NOTABUG if no response is
received within a week.

You still never answered my question.  If *you* already maintain your own
courier packages, why not use those instead of going through this whole review
process?

(In reply to comment #11)
> You still never answered my question.  
What is your question?

> If *you* already maintain your own
> courier packages, 
I don't maintain any courier related packages for now.

> why not use those instead of going through this whole review
> process?
So I don't understand for now what you want to say.

Generally, a review request is closed after inactivity of 
one month and one week.
http://fedoraproject.org/wiki/Extras/Policy/StalledReviews

Again setting NEEDINFO. I will close this bug as NOTABUG if no response is
received within a week.

Mamoru, the question was directed at Michael, who is the one reviewing this
package.  Please read the ticket history for context.

I do, and have done so for some time, well before I got involved in Extras - I
needed a good IMAP server that understood maildir and wasn't happy with
UW-IMAP+patches. This software probably taught me more about RPM than anything
else. :-)

(In fact I got asked about Courier F7 packages today in email - I'm still
downloading the release via torrent so builds are a way off yet).

I figured I'd review this one since I'm already familiar with the package and
it's always good to compare how others approach a fairly complex piece of
software from a packaging perspective. 

The package as it stands is in good shape and I'm happy to approve it if you can
fix up the init (standard policy to not start on boot, which I can certainly see
a benefit in even for this package) - the courier_release macro can go as
un-needed cruft for our purposes (it would make it more readable IMO) but I'd
really not look at this as a blocker.

I wouldn't worry too much about it diverging from upstream's - I'm sure it'll
get plenty of eyes to keep it trim (and I stand by my offer to comaintain it,
even for EPEL/CentOS as a recent job change has renewed my interest in these
releases) and most of the differences are really fairly small.

-- Michael.

Ping?

What is the status of this bug?

Dead - the submitter hasn't replied for 6 months or so.

Closing it now.

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