On Tue, 11 Sep 2012, Jeffrey Johnson wrote: > > 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.
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 ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org