On Sep 11, 2012, at 2:29 PM, Jan Rękorajski <bagg...@pld-linux.org> wrote:
> On Tue, 11 Sep 2012, Jeffrey Johnson wrote: > >> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski <bagg...@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 ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org