Re: Bug: PR server changes the PKGV variable too

[Mike Looijmans <mike.looijmans@topic.nl>]

On 01/05/2015 11:07 AM, Richard Purdie wrote:
> On Mon, 2015-01-05 at 10:41 +0100, Mike Looijmans wrote:
>> On 01/05/2015 10:27 AM, Richard Purdie wrote:
>>> On Sun, 2015-01-04 at 16:20 +0100, Mike Looijmans wrote:
>>> Imagine you're not using gitpkgv. You set:
>>>
>>> PV = "x.y+${SRCPV}"
>>>
>>> Since SRCPV contains a revision hash, you can end up in a situation
>>> where the version changes and you cannot upgrade the package since the
>>> hash didn't 'increase'.
>>>
>>> The PR server therefore combines with the git fetcher to add an
>>> incremental number at the start of the SRCPV string and yes, in that
>>> scenario, it acts as a PV server. This is actually working as designed.
>>
>> Then the design is wrong. If a package chose to override PKGV manually, then
>> the rest of the system should leave that value as is, and not touch it.
>> Apparently the recipe author knows better, so please let him use that wisdom.
>>
>> Also, if you change the architecture of the package, the PR server will reset
>> the version counter to 0 and break the upgrade path too. That was the problem
>> that caused me to discover this problem, the PR server is making it hard to
>> fix arch errors in recipes.
>
> You realise why it does that though? Imagine multiple MACHINE values
> being built against a PR server. Each MACHINE will have different
> package architecture values and different hashes. The 'PR' values should
> therefore be seen as different. If the system didn't do this, it would
> increment PR for every MACHINE change.
>
> Ok, so you say, lets make it work against MACHINE. That fails in the
> case where multiple MACHINES share a package architecture :/. Its not a
> simple problem to try and deal with :(
>
> I make no claim the system is perfect or free from bugs but these
> behaviours you're referring to are like this for various reasons. I'm
> open to changing them but we need to address the underlying problems
> like changing MACHINE above.
>
> There are several other issues with changing package architecture such
> as the sstate files in the sysroot. There is an open bug for this and
> right now, I simply don't know how to solve it properly :(.

Yeah, I stand corrected, this is not something easily fixed.

I'd still like to have a way to override the PR server. Is there a way to make 
the PR server ignore a package, or at least, have it NOT modify the PKGV 
variable for a package?
And if not, would you accept a patch to add that functionality to the prserver 
system?

>>> When you add in gitpkgv, something is obviously going wrong. gitpkgv is
>>> in meta-oe since I've refused to add it to core on the several occasions
>>> its been requested. I've said this before but I will say is again, it
>>> *needs* become part of the standard fetcher API rather than a hacked in
>>> afterthought which doesn't integrate well.
>>
>> I already volunteered and tried to do that, but got stuck in lack of
>> understanding how the fetcher works, and did not get any help so abandoned it
>> in favor of keep using gitpkgv "as is". I'm still volunteering, but without
>> help I can't do it.
>
> I'm struggling since to provide the help you need, I'd nearly have to
> solve the problem myself. I've helped several different people
> understand the fetcher in the past, only to have most of them move onto
> other things :(. Add in the 101 other distractions I have and its
> frustrating for everyone including me. Can you remind me where you were
> at (links to the right emails would help)?

This is basically as far as I got:

http://lists.openembedded.org/pipermail/openembedded-core/2014-October/098110.html





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/