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 2:29 PM, Jan Rękorajski <baggins at pld-linux.org> wrote:
> 
> > On Tue, 11 Sep 2012, Jeffrey Johnson wrote:
> > 
> >> On Sep 11, 2012, at 6:58 AM, Jan Rękorajski <baggins at 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