[OE-core] [PATCH 2/2] udev: enable multilib support

[Koen Kooi]

Op 7 apr. 2013, om 00:00 heeft Richard Purdie <richard.purdie at 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.purdie at 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.