rpm-5.4.10-22.i686 loops forever when installing ntpd-4.2.6p5-5.i686.rpm

Jeffrey Johnson n3npq at me.com
Fri Nov 30 21:04:04 CET 2012

On Nov 30, 2012, at 2:43 PM, Jan Rękorajski wrote:

> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>> On Nov 30, 2012, at 8:57 AM, Jeffrey Johnson <n3npq at me.com> wrote:
>>> The actual namespace and the intended semantic should be identified also:
>>> PLD is doing something different than other distros.
>> From git log
>> This patch fixes a bug with ntpd package we encoutered:
>> - ntpdate has "Conflicts: ntp < 4.2.0-3"
>> - ntpd has "Provides: ntp = 4.2.4" and "Provides: user(ntp)"
>> now, if ntpdate is installed then attempt to install ntpd causes
>> _rpmtsCheck to compare "C: ntp" to both "P: ntp" AND THEN "P: user(ntp)"
>> due to lack of dependency namespace check. Side effect of this is
>> infinite loop in _rpmtsCheck due to inner workings of rpm dependency
>> iterators.
>> There are 2 semantics for the namespace user(…) that will surely
>> cause additional issues. Something has to change to end (or unify)
>> the confused semantics.
>> What actions in PLD need the virtual provide
>> 	Provide: user(ntp)
> In short (quoting Jacek Konieczny <jajcus at jajcus.net>):
> 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.

OK, so _SOMETHING_ is using the Provides: as a reference count.

What is that _SOMETHING_? A script that invokes ??? to query an rpmdb???
Surely there's better/other ways to ensure that a group is removed on last erase.

Here's 2 possibilities:

And there's really little that is wrong with just relying on useradd/groupadd instead
of attempting to implicitly use a Provides: existence test.

For starters, rpm headers explicitly track all user/group assignments to files in metadata.
The Seqno index is persistent, and a counter for each user/group could be maintained.

> More here:
> http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2012-September/023057.html

Yes I thought I was repeating myself. As long as there are two semantics for
the user(…) and group(…) namespaces, I'm doomed to repeat myself yet again.

>> Can a different string choice be substituted?
> No can do, changing that will break a lot of already running systems.


Then we wait for the next occurrence all over again again again.

BTW, the patch you did is overly strict. Instead of drilling
the NS type everywhere, pass the "foo(bar)" original string around instead.

This is equivalent to ripping out "run-time probe" dependencies everywhere,
a patch for a feature regression I have no further interest in.

73 de Jeff
> -- 
> Jan Rękorajski                                 | PLD/Linux
> SysAdm                                         | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<at>pld-linux.org
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

More information about the pld-devel-en mailing list