As I mentioned yesterday, scripts in packaging systems are an opportunity to make mistakes. Thus, one thing that RPM could do to improve is to automate as many of the things that are done repeatedly in install and removal scripts (of which RPM has several variants).

There are two improvements that jump out at me. First, many packages only do things when they are being actually installed or removed instead of being upgraded (and sometimes do other things during an upgrade). Right now people detect these cases by boiler-plate shell script code, but RPM should make this available directly, by having scripts that are executed only in the appropriate context.

The second is that there are all sorts of generic types of files that want specific actions to be performed when they are installed or removed; for example, every time you install or remove a Gnome application it rebuilds the gconf schemas stuff. Right now (you saw this coming) everyone does this with standard boilerplate in scripts, which is bad.

Clearly we don't want the core RPM people to have to add specific actions and file types for every sort of semi-standard file that people invent. Instead RPM needs a mechanism where you can tag a file as having some arbitrary type, and a standard extension mechanism (such as shell scripts in a known place) to tell RPM what to do for each type. Then people building RPMs for Gnome applications would just tag their gconf schema files as the appropriate type and rely on the actions that the core Gnome people had defined to handle all the details.

(Then people could extend this with extra features, for example to automatically run a syntax checker over all files tagged as gconf schemas at RPM build time and complain if they were malformed. That would just be a build-time action for that type of files.)