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 ..."
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