rpm 5.4.10 for testing in th-test

[Jeffrey Johnson]

On Sep 11, 2012, at 4:49 PM, Jan Rękorajski <baggins at 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-devel at rpm5.org