[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RPM file list generation
RPM file list generation
Fri, 12 Jan 2001 13:54:14 +0000 (GMT)
I am working on a considerable improvement over our current rpm generation
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
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.
* 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
* 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.
* 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
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
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).
- RPM file list generation,
Nicola Pero <=