For another project, I learned how to write proper RPM spec files for
configure based source distributions.  I have enclosed a file that can
be used as a template for CSound, should the community decide to
distribute binaries as RPMs.  I've heard there is a program that
converts RPMs into Debian packages automatically, so that system can
also be supported.

Most of the RPM template was derived following Jos Vos' paper titled
'RPM packaging "the right way"'.

http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-vos.pdf

I was able to easily make the template work nicely with a source
distribution that uses automake and autoconf.

John

-----------------------------------------------------------
csound.spec.in
-----------------------------------------------------------
Name:		@PACKAGE@
Version:	@VERSION@
Release:	1
Source:		%{name}-%{version}.tar.gz
Vendor:		CSound Community

URL:		http://csound.sf.net/
Packager:	CSound project 
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-buildroot

Summary:	CSound Music Synthesis
License:	LGPL
Group:		Applications/Multimedia

PreReq:		/sbin/install-info

%description 
A description of the CSound package goes here.

%prep
%setup -q

%build
%configure
make

%install
rm -rf %{buildroot}
%makeinstall

%clean
rm -rf %{buildroot}

%post
if [ -f %{_infodir}/%{name}.info.gz ]; then
  /sbin/install-info %{_infodir}/%{name}.info.gz %{_infodir}/dir
fi

%postun
if [ $1 -eq 0 ]; then
  if [ -f %{_infodir}/%{name}.info.gz ]; then
    /sbin/install-info --delete %{_infodir}/%{name}.info.gz %{_infodir}/dir
  fi
fi

%files
%defattr (-, root, root)
%{_bindir}/*
%{_infodir}/*
%{_libdir}/%{name}/*
%{_includedir}/%{name}/*
%{_datadir}/%{name}/*

Can you compare with the csound.spec files already there?  Someone wrote 
those some time back and I did sometimes release RPM files.
==John

John ffitch  writes:

> Can you compare with the csound.spec files already there?  Someone wrote 
> those some time back and I did sometimes release RPM files.

Well, among other things, the one I sent assumes that "make install"
does the right thing, but the spec file in the csound module of the
repository has to do a lot of work to make up for the lack of a
configuration script.  With CSound 5, there will be a configuration
script, so tasks more properly carried out by "make install" can be
moved into the makefile.  The result is that "make install" can be
used to install a distribution equally as good as one produced by an
RPM.

John

OK; suggest you add to teh CVS, and maintain it.  I was only querying the 
status against the existing stuff.
==John

John ffitch  writes:

> OK; suggest you add to teh CVS, and maintain it.  I was only querying the 
> status against the existing stuff.
> ==John

I added csound.spec.in to the csound5 module and also ChangeLog.  I
stole text from csound.spec in the csound module for the %description,
and I assumed that a distribution should place binaries in ${bindir},
headers in ${includedir}, libraries in ${libdir}, and data files,
i.e., csound.xmg into ${pkgdatadir}.  In the default case,
bindir=/usr/bin, includedir=/usr/include, libdir=/usr/lib, and
pkgdatadir=/usr/share/csound.  To make this happen, I urge that the
name of the package be changed from Csound to csound, that is, in
configure.in, please change this line

AC_INIT(Csound, 4.24, csound-bug@cs.bath.ac.uk)

to the following line.

AC_INIT(csound, 4.24, csound-bug@cs.bath.ac.uk, Csound)

With this change, pkgdatadir, which naturally is assigned as
pkgdatadir=$(datadir)/%PROGRAM%, will receive the name one expects.
It also has the advantage that generated archives will receive
lowercase file names, and just as with directory names, most Unix
users prefer lowercase names.  The difference here is that without
this change, non-developers have to deal with uppercase file system
names.

One final note, if an installation is expected to install more than
one header file, I recommend they be installed into
$(includedir)/%PROGRAM%, not $(includedir).  This reduces the
likelyhood of conflicts.

John

Please ignore my request that the name of the package be changed from
Csound to csound in configure.in in the csound5 module.  The request
was based on an erroneous understanding of AC_INIT.  In fact,

    AC_INIT(Csound, 4.24, csound-bug@cs.bath.ac.uk)

defines

    PACKAGE = csound
    PACKAGE_NAME = Csound
    PACKAGE_TARNAME = csound

These are the desired definitions that go well with csound.spec.in.  I
apologize for any confusion I caused by my previous posting on this
subject.

John

ramsdell@mitre.org (John D. Ramsdell) writes:

> John ffitch  writes:
> 
> > OK; suggest you add to teh CVS, and maintain it.  I was only querying the 
> > status against the existing stuff.
> > ==John
> 
> I added csound.spec.in to the csound5 module and also ChangeLog.  I
> stole text from csound.spec in the csound module for the %description,
> and I assumed that a distribution should place binaries in ${bindir},
> headers in ${includedir}, libraries in ${libdir}, and data files,
> i.e., csound.xmg into ${pkgdatadir}.  In the default case,
> bindir=/usr/bin, includedir=/usr/include, libdir=/usr/lib, and
> pkgdatadir=/usr/share/csound.  To make this happen, I urge that the
> name of the package be changed from Csound to csound, that is, in
> configure.in, please change this line
> 
> AC_INIT(Csound, 4.24, csound-bug@cs.bath.ac.uk)
> 
> to the following line.
> 
> AC_INIT(csound, 4.24, csound-bug@cs.bath.ac.uk, Csound)
> 
> With this change, pkgdatadir, which naturally is assigned as
> pkgdatadir=$(datadir)/%PROGRAM%, will receive the name one expects.
> It also has the advantage that generated archives will receive
> lowercase file names, and just as with directory names, most Unix
> users prefer lowercase names.  The difference here is that without
> this change, non-developers have to deal with uppercase file system
> names.
> 
> One final note, if an installation is expected to install more than
> one header file, I recommend they be installed into
> $(includedir)/%PROGRAM%, not $(includedir).  This reduces the
> likelyhood of conflicts.
> 
> John