* Re: DORA RFC: FILESOVERIDES in dora
2013-11-18 11:15 ` Burton, Ross
@ 2013-11-18 11:18 ` Otavio Salvador
2013-11-18 12:46 ` Robert Yang
2013-11-18 15:37 ` Martin Jansa
2 siblings, 0 replies; 6+ messages in thread
From: Otavio Salvador @ 2013-11-18 11:18 UTC (permalink / raw)
To: Burton, Ross; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DORA RFC: FILESOVERIDES in dora
2013-11-18 11:15 ` Burton, Ross
2013-11-18 11:18 ` Otavio Salvador
@ 2013-11-18 12:46 ` Robert Yang
2013-11-18 14:25 ` Burton, Ross
2013-11-18 15:37 ` Martin Jansa
2 siblings, 1 reply; 6+ messages in thread
From: Robert Yang @ 2013-11-18 12:46 UTC (permalink / raw)
To: Burton, Ross, Richard Purdie; +Cc: openembedded-core
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DORA RFC: FILESOVERIDES in dora
2013-11-18 12:46 ` Robert Yang
@ 2013-11-18 14:25 ` Burton, Ross
0 siblings, 0 replies; 6+ messages in thread
From: Burton, Ross @ 2013-11-18 14:25 UTC (permalink / raw)
To: Robert Yang; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DORA RFC: FILESOVERIDES in dora
2013-11-18 11:15 ` Burton, Ross
2013-11-18 11:18 ` Otavio Salvador
2013-11-18 12:46 ` Robert Yang
@ 2013-11-18 15:37 ` Martin Jansa
2 siblings, 0 replies; 6+ messages in thread
From: Martin Jansa @ 2013-11-18 15:37 UTC (permalink / raw)
To: Burton, Ross; +Cc: openembedded-core
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread