rpm 5.4.10 for testing in th-test

[Jeffrey Johnson]

On Sep 11, 2012, at 5:22 PM, Jan Rękorajski <baggins at 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-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en