rpm 5.4.10 for testing in th-test

[Jeffrey Johnson]

On Sep 11, 2012, at 6:58 AM, Jan Rękorajski <baggins at pld-linux.org> wrote:

>> 
>> $ rpm -q rpm
>> rpm-5.4.10-0.12.x86_64
> 
> The problem comes from mpd and stunnel have Provides user(%{name}) and
> group(%{name}), and rpm mixes RPMNS_TYPE_USER/RPMNS_TYPE_GROUP namespace
> deps with RPMNS_TYPE_VERSION(?) causing P:group(%{name}) to behave like
> unversioned P:%{name} and satisfying that conflict:
> 
> D:   NO     A config(mpd) = 0:0.16.7-4  B mpd < 0.16.5-4
> D:   YES    A group(mpd)        B mpd < 0.16.5-4
> D: Conflicts: mpd < 0.16.5-4                                YES (db provides)
> D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4
> 

There is a namespace collision for user(…) and group(…).

As implemented @rpm5.org, the user(…) and group(…) namespaces
have a pre-defined semantic and are satisfied by lookup up
the user/group using getpwent(3) getgrent(3).

Specifically, "run-time probes" are _NOT_ satisfied by
examining package Provides:, but by looking up strings
using the usual glibc name services.

(aside)
At some point the implementation will be extended so that
	Provides: user(foo) = N
will add an entry to /etc/passwd (where N = the desired uid),
withe removal mapped to an Obsoletes:

> Shouldn't rpmdsCompare test if the comparison is in the same namespace?
> 

rpmdsCompare() already SHOULD have this behavior: the routine
won't be called for user(…) and group(…) name spaces.

(aside)
BTW, it would have been far easier if you had chosen
to discuss issues before upgrading to rpm-5.4.x.

Reactively re-vetting incompatibilities as discovered
is in noone's interest because of the tyranny of
	Upgrades MUST "work".
because all that will, happen is PLD will rip out every
implementation that has been accomplished over the past
few years to achieve
	Have it your own way!
which is indistinguishable from a "fork".

I personally have little interest in re-visiting
what is now ancient (>3y ago) hysteria.

I have offered repeatedly to assist PLD upgrades and
both arekm/glen SHOUL be aware of all of the changes,
and have had an opportunity to discuss incompatibilities
and rationales when these changes were made years ago.

hth

73 de Jeff