On Sep 11, 2012, at 5:22 PM, Jan Rękorajski <bagg...@pld-linux.org> wrote:
>> >> 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. > Because I lack specifics, I need clarification: Is the Provides: group(mpd) retrieved from Providename index in rpmdb matching a Conflicts: mpd < 0.16.5-4 from a package header in the code you posted? That's broken imho (and I should have enough details to find the flaw if/when you confirm). (aside) The easy work around is removing Provides: group(md5) although I lack sufficient details on what is/was intended with that dependency to say for sure. Removing the Provides: SHOULD prevent the Conflicts: from firing. >>>> 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)? > The confusion is likely that I wasn't sure whether it was a user(…) or a group(…) dependency which are quite similar in form. Perhaps I should have said Provides: group(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. > There's no well defined semantic for Provides: group(mpd) even if PLD has adopted some convention afaik. The Provides: group(mpd) is just a string and (imho) should be removed if there are problems unless there is truly some explicit PLD implementation that relies on the adopted convention. (aside) The future intent @rpm5.org is to overload Provides:/Obsoletes: as a means to automate adding/deleting entries in /etc/passwd and /etc/group (where there will be an explicit semantic attached to the namespace(s). The only show stopping issue is committing to a tuple serialization that maps onto the necessary fields needed in /etc/passwd etc with reasonable defaults for missing values. Consensus on representations in *.spec is always rate limiting: it literally takes years before the complaints from package monkeys disappear, sigh. hth 73 de Jeff > -- > 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...@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org