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

dep in question is of the TYPE_VERSION here, comes from package being
installed and it is 'mpd < 0.16.5-4'
'group(mpd)' comes from the rpmdb Provides iteration later on.

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

Thanks in advance :)

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

Hmm, besides not being able to find that particular probe in rpm5
source (may be me tired), how can we tell that _this_ package provide
_that_ username other than specyfying Provides: user(mpd)?

I always considered user() and group() provides as a means to tell that
those user/group names come from the package having appriopriate Provides.

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