rpm 5.4.10 for testing in th-test

[Jan Rękorajski]

On Tue, 11 Sep 2012, Jeffrey Johnson wrote:

> 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:

What abous stuff like homedir, gecos, supplementary groups, etc.?

> > 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.

As you can see above it is called with 'mpd < 0.16.5-4' dep from
installed package (this is the code path that skips NSType user/group)
and 'config(mpd) = 0:0.16.7-4' and 'group(mpd)' from db iteration which
have no NSType checking.

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

Unfortunately the only problems that I was aware of was some 3y old
segfaults :(

> 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".

Currently the only incompatibility is P:user()/group() we're talking
about here. And it looks to me like unchecked code path issue we
can fix and be both happy.

Believe me I don't want to introduce incompatibilities as those will
make my life harder later on maintaining them.

> 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.

-- 
Jan Rękorajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org