Developers of Sympa

[Guillaume Rousse <address@concealed>]

David Verdin a écrit :
> Hi Jason,
> 
> Thanks for sharing this code!
> We are currently working on the improvement of the autotools usage in
> Sympa, thanks to the work of G. Rousse.
> Your work will take place in this wider context.
Building rpm (or distributions packages, more generally) is outside
intended autotools purpose, probably because it's too specific and it's
outside software maintainer role. Packages are usually maintained
separatly by third party, from distributed tarballs, and don't require
any specific support (excepted standard GNU build system features, such
as 'make install DESTDIR=' style support).

Of course, software authors may be interested either in distributing rpm
themselves (bad idea, IMHO, unless you're willing to deal with X
distributions, Y versions and Z architectures), or to distribute
software ready to be transformed into rpm for their users (far more
generic solution). But you don't need any 'make_rpm' target in your
makefile for this: just having a spec file in your top-level directory
of your archive allow anyone to run 'rpmbuild -ta sympa-x.y.z.tar.gz'.

sympa currently has make targets for generating mandriva and redhat
packages. I don't see much use for the mandriva target, as I already
maintain sympa inside mandriva. Just moving the spec file Jason
submitted at the top-level of sympa archive, and dropping anything
related to rpm building in Makefile.am would remove a lot of cruft,
while retaining needed functionality.

Note however there is a chicken-and-egg issue currently, as this spec
file is actually not a spec file, but a spec file template, with
intended substitution target for sympa installation process. A spec file
is not supposed to be a result of a first ./configure script execution,
embedding values passed by the user, to call the same script with the
same parameters, but drive the configuration process itself (see
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sympa/current/SPECS/
for an example). This is over-complex, fragile, and counter-intuitive.
You'd rather replace this ugly mess with a static spec file, and if
you're really worried about the potential mismatch between its version
and tarball version, make the related substitution part of the sympa
release process, not of the final user configuration process.

-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62