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 _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en