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

[Richard Purdie]

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. There is no
mechanism to force conflicts between two different multilibs easily
though and the system can still end up trying to install both packages
with conflicting binaries which it needs a resolution to.

So either we set udev to use paths which don't overlap with the lib
handling or we hack the multilib code, each of the package managers and
sanity tests.

Cheers,

Richard