On Tue, 11 Sep 2012, Jeffrey Johnson wrote: > > 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).
Nothing special there, AFAIR. > >>> D: package systemd-187-4.x86_64 has unsatisfied Conflicts: mpd < 0.16.5-4 > >>> > >> [...] > >>> 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? No, it's pure 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. No, it's this piece of code in rpmlib lib/depends.c:~1450: 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. > 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 > >> 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. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ baggins<at>mimuw.edu.pl baggins<at>pld-linux.org _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en