RPM file list generation

[Nicola Pero]

Hi, 

I am working on a considerable improvement over our current rpm generation
code.

To generate an rpm, the biggest task (actually, the only non trivial one)
is to build the `file list'.  The file list is the list of files which are
to be included in the rpm and installed/removed when the rpm is
installed/removed.

Currently, rpm.make needs to contain code specific to each type of
project, and whenever a subproject of a certain type is built, it adds to
the file list a certain number of files, determined by code tuned for the
type of package being built.  This code is hard-coded inside rpm.make.

I suggest we could change the approach for our 2nd generation rpm support.  


My idea is that typing

'make filelist=yes install'

will cause INSTALL_DATA, INSTALL_PROGRAM, MKDIRS, to be redefined to be
some logging shell scripts, which append the name of the files/directories
to install to the filelist, rather than actually installing them; then the
`install' target is built `normally'.

In this way, the list of installed files is automatically generated.

I have already implemented this, and it mostly works - some tuning (see
below) is still needed.  I put it into a separate file file-list.make,
which can be reused for other packaging systems as well - actually it just
builds the file list so it's completely package independent.

Advantages: 

 * if all installation is done through the same scripts INSTALL_DATA,
   INSTALL_PROGRAM, MKDIRS, then the stuff works always and automatically, 
   without need to write/review/debug the code to build the file list for
   all the different packages we have.

 * When we change the package code, we don't need to change the file list.

 * If a 3rd party implements a 3rd party (possibly private) kind of
   package - as soon as he makes sure of always using INSTALL_PROGRAM etc 
   to install its files and dirs, the make package can automatically
   generate the file list for his/her package, without need to hack
   rpm.make.

 * Code can be reused with *any* packaging system.  Basically the
   difficult task with all packaging systems is building the file list, 
   so adding support for different packaging systems should be easy.

Disadvantages:

 * for libraries, there would only be a single package, because headers
   can't be easily separated from other files.  <I personally think this
   is a feature rather than a disadvantage because I prefer a single
   package, containing library binaries + headers>

 * in general, it will be more difficult to generate package-specific 
   custom behaviours.  The file-list contains all what is installed 
   automatically, but it doesn't separate, say, doc from executables or
   images or from headers.  Anyway, once you have the file list, if you
   want to separate, say, the headers, you can still grep for files *.h
   in the list etc.


To make everything work satisfactorily, some hacking is still needed:

1. We install applications and bundles using 

   $(TAR) cf - $(BUNDLE_DIR_NAME) | (cd $(BUNDLE_INSTALL_DIR); $(TAR) xf
-)

  this does not use INSTALL_PROGRAM etc and so can't be logged into the
  spec file.

  Solution: create a shell script `installdir.sh' which installs a dir
  and all its contents somewhere.  The shell script basically contains 
  $(TAR) cf - $(DIR_TO_INSTALL) | (cd $(WHERE_TO_INSTALL); $(TAR) xf -)

  Add a variable 

  INSTALL_DIR_SCRIPT = $(GNUSTEP_MAKEFILES)/installdir.sh

  Replace all occurrences of the pattern in the makefiles with a call to
  this shell script.

  Create an appropriate logging shell script, and when filelist=yes,
  redefine INSTALL_DIR_SCRIPT to call the logging shell script instead of
  installdir.sh

2. Often, MKDIRS is used not to install, but to create dirs locally (eg, 
   the directory structure below XXX.app/).

   Solution: clearly separate MKDIRS (to be used locally) from
   MKINSTALLDIRS (to be used to install).  Normally, the two vars would 
   have the same value; when filelist=yes, we redefine MKINSTALLDIRS 
   but *not* MKDIRS.

 3. I'm not sure this is really compatible with the way the core package 
    is configured and compiled as a whole (would certainly work for
    subpackages as single entities)

Both 1. and 2. should be quite easy to implement - I'll do them this
afternoon.  Need to look into 3 - but I think we should drop the core
package and break it into the subpackages.  Prepare a make package rpm/deb
and ask people to install it first of all.

It would be much easier for the great public to install from separate rpms
(make, base, gui+xgps), rather than a big source code.

Please if there is some serious objection to this design, would people
inform me before I do a commit (I won't touch rpm.make yet, but I'm
worried about the changes to MKDIRS etc).