It would be nice to have a way of making a single package file that would actually contain multiple full-blown packages. The main idea with this is that by making the sub-packages have their own entries in the RPM database, they could be upgraded separately or could upgrade an already present package if the existing package is older. Example: you have a combo package named foo-1.2-1.i386.rpm that contains foo1-1.2-1.i386.rpm and foo2-1.1-6.i386.rpm. Doing this command: rpm -Uvh foo-1.2-1.i386.rpm would be exactly the same as doing this one: rpm -Uvh foo1-1.2-1.i386.rpm foo2-1.1-6.i386.rpm Together with "patch packages" (#7121), this would be nice (would enable things like Sun's "combo patch").
I believe this is called transaction sets, and it might be implemented already. jbj would have to comment on it though.
Actually, these are what I call "package bundles", which are now possible because the rpm database permits concurrent access. That means you can make a meta rpm that runs "rpm -Uvh ..." in %post, and "rpm -e ..." in %preun. Dunno if it works, but all the above is now implemented, so I'm gonna close this bug.
Where would the sub-packages RPM files be stored? I wouldn't want a "foo" meta-package that contains a "foo1" and a "foo2" RPMs to leave these RPMs around in some directory all the time that it exists. Can you have files part of a package that are not "installed" on the system (they would be deleted after %post, maybe?).