Thoughts about courier-mta packaging?

[Michael Schwendt]

On Fri, 09 Jun 2006 13:36:11 -0700, Chris Petersen wrote:

> > There is nothing wrong with starting from the upstream spec.  It will
> > have to adhere to the standards though, no flexibility on that.  It
> > would be best if upstream could accept the changes you have to make so
> > that life is easier.
> 
> well, since one of the standards is "no other-distro stuff in the spec,"
> that makes courier's incompatible.  My main concern is that it's
> designed to build an rpm -- on any rpm-based distro.  I can clean up the
> stuff that would annoy rpmlint, possibly the group name (nonstandard),
> but I'm not about to maintain it in such a way that I always have to
> pull out Sam's non-fedora customizations.
> 
> For reference, the file is available at:
> 
> http://courier.cvs.sourceforge.net/courier/courier/courier/courier.spec.in?view=markup
> 

This one is a funny incarnation of the infamous superfluous buildroot
check in the spec:

> test "$RPM_BUILD_ROOT" != "" && rm -rf $RPM_BUILD_ROOT

It's even less useful than checking whether buildroot is set to '/'. :-)


Note that the buildroot == '/' check still seen in spec files occasionally
is from times when the "BuildRoot:" tag in spec files was not mandatory
and when scripts in rpmbuild did not check it either. I think it is a myth
that package builders commonly lost their root directory because of this.
Personally, I don't know anybody who has been hit by "rm -rf /" going wild
during rpmbuild. But I've seen the occasional report of typos causing
many others scripts to do this, where "safety checks" failed to recognise
root == // or root == '/ ' and in one very old case even $RPM_BUILD_ROOT/


Back to the courier spec, I find it overly big and complex. Screen-filling
Perl helper functions, which generate %attr(...) values on-the-fly,
redefinition of several globals, e.g.

> %define _missing_doc_files_terminate_build 1
> %define _unpackaged_files_terminate_build 1

> %define __libtoolize /bin/true

even a "%define configure ...",

> AutoProv:         no

spec sections with a comment like

> # Break up a single filelist into multiple packages right here.  This is
> # going to be ugly.

> ## Ok, upgrades are going to get ugly. 

lots of "sed" usage, build-time generated profile.{sh,csh} scripts,
inline Perl script usage, chown in %post (!),

> chown --reference=%{_sysconfdir} %{_sysconfdir}/userdb

triggerpostun scriptlets which mess with .rpmnew files. This package
looks pretty much like a maintenance nightmare. I wonder why the
install process is not simplified with more work in "make install"?