On Sep 11, 2012, at 4:49 PM, Jan Rękorajski <bagg...@pld-linux.org> wrote:
>>
>
> No, it's this piece of code in rpmlib lib/depends.c:~1450:
>
Got it …
> mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, Name, 0);
> (void) rpmmiPrune(mi,
> ts->removedPackages, ts->numRemovedPackages, 1);
> while ((h = rpmmiNext(mi)) != NULL) {
> if (rpmdsAnyMatchesDep(h, dep, _rpmds_nopromote)) {
> rpmdsNotify(dep, _("(db provides)"), rc);
> mi = rpmmiFree(mi);
> goto exit;
> }
> }
> mi = rpmmiFree(mi);
>
> dep here is 'mpd < 0.16.5-4', and it goes through all NSType checks,
> h becomes 'group(mpd)' and is never tested if its NSType matches the dep
> it is compared to.
>
… that code should not have been traversed.
I'm expecting this code in lib/depends.c:955 to catch user(…) and group(…):
/* Evaluate user/group lookup probes. */
if (NSType == RPMNS_TYPE_USER) {
const char *s;
uid_t uid = 0;
s = Name; while (*s && xisdigit(*s)) s++;
if (*s)
xx = unameToUid(Name, &uid);
else {
uid = strtol(Name, NULL, 10);
xx = (uidToUname(uid) ? 0 : -1);
}
rc = (xx >= 0 ? 0 : 1);
if (Flags & RPMSENSE_MISSINGOK)
goto unsatisfied;
rpmdsNotify(dep, _("(user lookup)"), rc);
goto exit;
}
if (NSType == RPMNS_TYPE_GROUP) {
const char *s;
gid_t gid = 0;
s = Name; while (*s && xisdigit(*s)) s++;
if (*s)
xx = gnameToGid(Name, &gid);
else {
gid = strtol(Name, NULL, 10);
xx = (gidToGname(gid) ? 0 : -1);
}
rc = (xx >= 0 ? 0 : 1);
if (Flags & RPMSENSE_MISSINGOK)
goto unsatisfied;
rpmdsNotify(dep, _("(group lookup)"), rc);
goto exit;
}
Any idea why the code above isn't being traversed? I'm
missing something here, any help appreciated.
>> 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.
>
> I don't know if they're worth you attention, all of them seem outdated:
>
> - headerGet() making poldek segfault http://rpm5.org/cvs/tktview?tn=38,1
> - rpm doesn't exit when no sources/patches available
> http://rpm5.org/cvs/tktview?tn=40,1
> - http://rpm5.org/cvs/tktview?tn=41&_submit=Show
> - when adopting, use 4.5 ticket for checklist:
> https://bugs.launchpad.net/pld-linux/+bug/262985
>
I will look later tonight (to ensure actually fixed).
>>>> 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.
>
> AFAIK, even our rpm 4.5 has "run-time probes" like uname(release),
> so they're not the problem here. I can live with some level of legacy
> breakage, one have to cut off the long tail sometime.
>
Good (I've mostly forgotten whether probes are in rpm-4.5 these days).
But if using "run-time probes", then I'm not sure why
there are
Provides: user(mpd) …
dependencies being added. Or am I confused somehow?
73 de Jeff
> --
> Jan Rękorajski | PLD/Linux
> SysAdm | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<at>pld-linux.org
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-de...@rpm5.org
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
