Op 7 apr. 2013, om 00:00 heeft Richard Purdie <richard.pur...@linuxfoundation.org> het volgende geschreven:
> On Sat, 2013-04-06 at 12:32 +0200, Koen Kooi wrote: >> Op 5 apr. 2013, om 16:34 heeft Richard Purdie >> <richard.pur...@linuxfoundation.org> het volgende geschreven: >> >>> 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. >> >> >> FWIW, the udev *libraries* (libudev, libgudev, etc) go in >> $prefix/lib64 on 64 bit machines, the udev *binaries* into /lib. So >> multi*lib* should work. > > Which is effectively what I said. > > multilib package A has binary X in /lib. multilib package also B has > binary X in /lib. Package A and B cannot be installed at the same time > (package managers can't cope) and the sanity tests will fail. > > Sure, we can force the libraries to be in separate packages. For udev and systemd each and every library has its own subpackage already, so that isn't a problem here. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
