rpm 5.4.10 for testing in th-test

[Jeffrey Johnson]

On Sep 11, 2012, at 2:29 PM, Jan Rękorajski <baggins at pld-linux.org> wrote:

> 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)
>                                                             ^^^^^^^^^^^^^^^^^^^^^^^

Yes, already noted (but I do not know what patches
you are applying).

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

(aside)
Yes there is a tuple of information that needs to be
well defined. This is no harder than defining some character
like ':' to serialize the tuple.

The harder issue will be permitting white space in *.spec
parsing, where the feeble/naive parsing to next ',' or white
space that is currently being parsed will have to be improved.

None of this is rocket science. And this isn't the
time or place to discuss the best way to automate
passed/group management within overloading RPM
	Provides: user(foo)
	Obsoletes: group(bar)
syntax to add/delete user/group items.

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

So its called from poldek, not from rpmlib lib/depends.c?

Yes: you need to parse the user(…) and group(…) namespace
wrappers similar to what is being done in unsatisfiedDepend()
near lib/depends.c:868.

Then there is the further design decision to decide
how to interpret user(…) and group(…) wrappings
with poldek+rpm to maximize "legacy compatibility" and
minimize maintenance.

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

Post the details at launchpad.net/rpm and I'll sort
the segfaults for you.

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

Hard to say what happy means from here without knowing
what is being proposed. But yes, an accidental name collision
can be sorted without pain. The hardest issue is
	What about "legacy compatibility" with versions
	of RPM that do not have "run-time probes"?
The better approach is back porting, but otherwise
"run-time probes" are merely serialized strings that can be stubbed
out in older versions of rpm without too much difficulty.

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

Good (neither do I).

73 de Jeff