DORA RFC: FILESOVERIDES in dora

DORA RFC: FILESOVERIDES in dora

[Richard Purdie]

We have an issue in the dora branch at the moment. When I merged in the
set of bug fixes post release, I added:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=dora&id=0bd63125c3b44a656e44f2a76cc5f832c9db4bbd

which wasn't entirely intentional. It changes the behaviour of
FILESOVERRIDES. The bug there is real with "arm" overrides being
preferred to "armv7a" for example and other strange/incorrect ordering.
It was in fact impossible to override certain things which people needed
to in some circumstances and defeated the purpose of OVERRIDES.

I don't doubt this change is correct in master, the question is whether
it should be in dora. The issue is that some layers don't work correctly
before/after the change and we now have a bit of a confused situation.

Our options are either:

a) Revert the change in the branch. Anyone who adapted to the correct
behaviour on the branch would need to revert those changes

b) Keep this change in there and adapt layers to fix any incorrect
behaviour.

I'm open to either option but I think this needs discussion before we do
anything. I'd appreciate other people's views, particularly those of
layer maintainers.

Cheers,

Richard

Re: DORA RFC: FILESOVERIDES in dora

[Burton, Ross]

On 18 November 2013 11:10, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> a) Revert the change in the branch. Anyone who adapted to the correct
> behaviour on the branch would need to revert those changes

As there hasn't been a .1 of Dora yet this only impacts people who
have been tracking git, so I think it's probably best to apologise for
this merge and revert it, on the grounds that it's a serious behaviour
change.

Ross

Re: DORA RFC: FILESOVERIDES in dora

[Otavio Salvador]

On Mon, Nov 18, 2013 at 9:15 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 18 November 2013 11:10, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> a) Revert the change in the branch. Anyone who adapted to the correct
>> behaviour on the branch would need to revert those changes
>
> As there hasn't been a .1 of Dora yet this only impacts people who
> have been tracking git, so I think it's probably best to apologise for
> this merge and revert it, on the grounds that it's a serious behaviour
> change.

I agree with Ross here.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: DORA RFC: FILESOVERIDES in dora

[Robert Yang]

On 11/18/2013 07:15 PM, Burton, Ross wrote:
> On 18 November 2013 11:10, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> a) Revert the change in the branch. Anyone who adapted to the correct
>> behaviour on the branch would need to revert those changes
>
> As there hasn't been a .1 of Dora yet this only impacts people who
> have been tracking git, so I think it's probably best to apologise for
> this merge and revert it, on the grounds that it's a serious behaviour
> change.
>

I'm afraid that the problem is it doesn't work well after revert the patch,
either, as the patch says:

Currently the overrides are being applied backwards. This means something
which is platform specific is overriding something which is machine specific
which is clearly not intended.

I don't know how many layers are affected, I've tested the current dora branch
in the local autobuilder, didin't find any errors.

// Robert

> Ross
>
>

Re: DORA RFC: FILESOVERIDES in dora

[Burton, Ross]

On 18 November 2013 12:46, Robert Yang <liezhi.yang@windriver.com> wrote:
> I'm afraid that the problem is it doesn't work well after revert the patch,
> either, as the patch says:

Sure, but Dora's been released and tested: changing the behaviour
there in a branch means huge amounts of validation will need to be
done.  Just how long has the order been wrong?

Ross

Re: DORA RFC: FILESOVERIDES in dora

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

On Mon, Nov 18, 2013 at 11:15:07AM +0000, Burton, Ross wrote:
> On 18 November 2013 11:10, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > a) Revert the change in the branch. Anyone who adapted to the correct
> > behaviour on the branch would need to revert those changes
> 
> As there hasn't been a .1 of Dora yet this only impacts people who
> have been tracking git, so I think it's probably best to apologise for
> this merge and revert it, on the grounds that it's a serious behaviour
> change.

I agree with Ross, it would be really bad to ask people if they use
dora as 1.5, 1.5.1 or what exact revision between them when debugging
some FILESPATH related issue.

BTW: https://wiki.yoctoproject.org/wiki/Releases still says Dora is in
development, that note should have been dropped when links to 1.6. were
added.

FWIW: I'm not sure if I like reversed for loops, commit says "give the
result the user would expect", maybe I'm just used to old behavior, but
I expect e.g. version specific patches to be preferred over DISTRO specific
patch in "files" directory.

Imagine hypothetical case:

conman_123.bb:file://static-configuration.patch
connman/qemuall/static-configuration.patch  # something qemu specific to keep NFS root mounted
connman/static-configuration.patch

someone adds new connman with different configuration format
connman_345.bb
connman-345/static-configuration.patch      # new format required for 345 and we don't need qemuall to override it anymore

With for loops reversed connman_345 will use old connman/qemuall/static-configuration.patch

Someone can show similar case where the reversed order makes sense.

But I think that people will usually notice version change and if needed
update distro/machine specific files to provide their own variant for
new recipe version.

E.g. if connman gets broken between 2 images I'll easily see in
installed-packages.txt that connman was upgraded end quickly find that
our specific .patch file wasn't used anymore. But I won't notice that
someone added new file to qemuall which caused only EXTENDPRAUTO change
and rebuild with different file.

Is it right thing to change behavior people are used to? Especially if
it doesn't fix any real-world issue (Not talking about changed order of
overrides which makes sense to me).

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]