Richard Purdie <richard.pur...@linuxfoundation.org> writes:
>> >> Following the example set by udev, move the binaries to /sbin/systemd
>> >> and hardcode less paths in general. Tested on atom-pc with a .hddimg
>> >> so the live boot/initrd paths were tested.
>> >
>> > At least the moving of udev breaks a lot of local recipes here which
>> > install e.g. local rules or keymaps in /lib/udev. This is a silent break
>> > which is detected at device runtime only. The global 'bitbake.conf' has
>> > not been updated for the new paths neither.
>> >
>> >
>> > There should be:
>> >
>> > 1. added some QA checks which detect this broken packaging
>> >
>> > 2. added some global variables (e.g. 'udev_basedir') which can be used
>> > in the rules.
>>
>> These patches can get NAK'd all you want, but they will go in. I still
>> say: NAK, this is a bad, bad idea. It diverges from upstream and
>> introduces silent breakage as you point out due to that.
>
> In the 1.5 timeframe I want to look at this again and see how we can
> better solve it as it may be we can do something to the multilib code to
> avoid the issues. We ran out of runway with this for 1.4 :(.
Does this mean, this last-minute and invasive patch gets reverted (-->
it is already in oe). Or, that it stays and we have to live in 1.4 with
bad surprises[1] because an undefined number of packages[2] uses still
the upstream defaults?
Enrico
Footnotes:
[1] udev rules, keymaps and firmware at the wrong location
[2] surprisingly, 'systemd' itself where this change has been applied
still refers to /lib/udev/rules.d
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
