rpm 5.4.10 for testing in th-test

[Jacek Konieczny]

On Tue, Sep 11, 2012 at 11:06:45PM -0400, Jeffrey Johnson wrote:
> There's no well defined semantic for
> 	Provides: group(mpd)
> even if PLD has adopted some convention afaik. The
> 	Provides: group(mpd)
> is just a string and (imho) should be removed
> if there are problems unless there is truly some
> explicit PLD implementation that relies on the adopted
> convention.

There is.

PLD. Packages with 'Provides: group(mpd)' call the '%groupadd' macro
during installation, which creates the group if it is not already
defined. When uninstalled they call the '%groupremove' macro.

The same 'group(mpd)' may be provided by multiple packages (probably not
much sense with the 'mpd' group, but important for other cases) and the
group will be removed only when the last package which provides it is
removed. So the 'Provides: user(*)' and 'Provides: group(*)' are
critical for our %{user,group}{add,remove}  macros.

Other solutions to the problem (multiple packages using the same
user/groups) would be:
- including every system uid/gid in the 'setup' package. 
  Disadvantages: lots of unneeded user and groups defined on every PLD
  system and the need to update the setup package whenever user/group is
  needed for anything else.
- providing each such user/group/user&group via a single packages
  Disadvantages: some packages would be created only to hold a single
  user or group definition.
- never removing users/groups added
  Disadvantages: mess left after uninstalled packages

Our useradd/groupadd macros with 'Provides: user/group(*)' seem to be
quite an elegant solution in comparison and RPM 5.x still doesn't seem
to provide anything better.

Greets,
        Jacek