One of the uses of a package group is to install the entire group in one go. The problem is that once the group is installed any changes to the group are not reflected on the user's system, somewhat limiting its utility for this purpose. Ideally, metapackages would be used for this purpose, but the reality is that packagers may not be able or willing to maintain a proper metapackage and it would often be difficult and tedious for end-users to manage them personally. This would only be suitable for groups that are intended to be installed in their entirety (i.e. they don't have any internal conflicts). Something like the Arch Linux `gnome` and `gnome-extra` groups are what I have in mind, or the `base` group before it was converted to a metapackage. This would add a new option, tentatively called `KeepGroup` or `SyncGroup` that would have the following effects for any group listed:
* during sysupgrade, any group members not currently installed would be added to the transaction
* if a group package cannot be added to the transaction because of a conflict, the transaction fails
* removing a member package would prompt similar to `HoldPkg`
* group members would be considered required for the purposed of `-Qt`, `-Ru`, and `-Rs`, possibly behind a new option
* possibly install member packages as dependencies when installed via group name rather than individually?
* should this have any interaction with `IgnorePkg` or `IgnoreGroup`?
I think the main downside to this is simply its inferiority to proper metapackages and possibly some confusion when used with groups not suitable for full installation. Unfortunately, metapackages do incur additional logistical and maintenance costs that mean they may not always be practical. This might be a good in-between for those cases where the benefits of a proper metapackage do not justify those costs.
↧