On Fri, 2013-04-05 at 16:29 +0300, Alex Damian wrote: > On udev-184 they changed the default location from /sbin/ > to /lib/udev/ and I kept same as the upstream is.
Firstly, I know some people did ask me questions offlist about this and I probably gave misleading answers. I thought this was a problem with the location of the rules directory initially. We need to have one rules directory regardless of multilibs. Binaries however are a very different question. The multilib code we have in OE is complex and does make some assumptions about layout, not least as we have to interface into several package managers and also work with all their assumptions. The situation is that: * library files are expected to go into /libX * binaries are expected to go into the usual bin/sbin dirs * files in /etc, /usr/share and other similar directories are expected to be identical * We have sanity tests which check for these things The package managers are taught to let certain packages "win" in bin/sbin and to error if overlapping files outside this are not identical. It therefore follows that we would have to start adding exceptions to this code if we have potential for both 32 bit and 64 bit /lib/udev/ binaries. We'd also have to add rules about which one would be expected to "win" under which circumstances and so on. To me, the simplest solution here is to point libexec dir at /sbin so that we have /sbin/udev/ since this then works with the various multilib rules. It means a user can install the 64 bit and 32 bit multilibs for udev in parallel (for libudev for example) and that things should all work correctly. I appreciate upstream don't agree with that approach but equally they don't have the generic multilib support we have to worry about. Hacking the multilib code to pieces just to match upstream in this case is going to be a lot more painful, I appreciate its the not optimal solution though. There is some pressure here since I would like the release to have working multilib support as well as sysvinit and systemd :/. Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
