Improving RPM as a packaging system
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.)
Why package systems are important
Once upon a time it was popular to laugh at package systems like RPM
and say that all you really needed was '
make install'. This attitude
missed the point, because the importance of good package systems is
that they let you easily remove things.
This matters because it encourages experimentation with packages. If removing a package is difficult and painful, it's a fairly big commitment to just install a package in the first place. If removing a package is easy and reliable, then installing packages is not at all a commitment; if it turns out to not be useful, you just remove it again. When it's easy enough, installing a package temporarily may become the easiest way to merely read about the package.
(Having lots of unnecessary packages is a form of clutter, and like all clutter makes your systems harder to manage. It may also expose you to more security issues, and it eats up more disk space, and so on.)
This implies that one of the things that a good package system should do is have as little done by install and removal scripts as possible. Scripts are an opportunity for people building packages to get things wrong, and it only takes a few mistakes to lose people's trust. Putting every routine operation in the package system itself means that only one set of people have to get it right, and they generally have a much deeper and broader exposure to the issues.
(Of course there are other things that competent package systems do to encourage experimentation, like automatic dependency resolution. But a good package system should have a way of removing a specific package and all packages that were only installed as dependencies; as far as someone experimenting with a package is concerned, they're all one thing.)