[oe] [RFC] Fix udev pulling in libvolume-id-dev

[Denys Dmytriyenko]

On Thu, Jan 15, 2009 at 10:51:59AM -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 14, 2009 at 11:37:10PM -0800, Khem Raj wrote:
> > On (15/01/09 01:14), Denys Dmytriyenko wrote:
> > > I was debugging the strange behavior of one of my boxes pulling in libc6-dev 
> > > into the filesystem image and it happened to be because udev pulled in 
> > > libvolume-id-dev instead of libvolume-id0... It worked as expected on the 
> > > other box, though.
> > > 
> > > Several people on IRC have seen this lingering bug before, but no fix was 
> > > available. Koen mentioned it got fixed for him by rebuilding udev...
> > > 
> > > After some investigation I found out that both libvolume-id packages (-dev and 
> > > regular) are registered to provide libvolume_id.so.0 and the one appearing 
> > 
> > I think -dev provides libvolume_id.so and libvolume-id provides
> > libvolume-id.so.* they are different. Our shlib handler should be able
> > to figure that out. I still wonder what caused it to pull libc-dev
> > though.
> 
> The shlib handler from the package.bbclass examines every package by running 
> objdump and looking for SONAME/NEEDED sections of all the executables and 
> lib*.so files. So, the real .so library from libvolume-id gets identified as 
> a provider for libvolume_id.so.0, which is correct. Then libvolume-id-dev 
> gets examined, and it does not provide any shlibs. But since it has a symlink, 
> which points to a real host .so, objdump picks up its SONAME and -dev gets 
> also identified as a provider of libvolume_id.so.0, which is wrong.
> 
> Since most of other libraries with -dev split have either relative symlinks 
> (../..) or pointing to the same directory, they never get into this issue, 
> becuase when -dev is examined, the symlink is broken, as -dev gets installed 
> into a separate directory.
> 
> That's the reason for my patch to package.bbclass to skip symlinks when 
> running objdump.
> 
> libc-dev gets pulled in by libvolume-id-dev, for some reason, according to:
> libvolume_id_dev -> libc6_dev [style=dotted];
> 
> > > last in os.walk() gets pulled in by udev. The order of files provided by 
> > > os.walk() depends on parallel builds and phase of the Moon.
> > > 
> > > libvolume-id-dev does not provide the actual .so library, but it contains a 
> > > symlink in /usr/lib, which points to /lib/libvolume.so.0 (the host one!) 
> > > instead of ../../lib/ one...
> > > 
> > > The first patch attached fixes this in udev and should be a no brainer. Unless 
> > > someone objects, I'll push it in in a day or two.
> > 
> > Seems like we need this to work in a sysrooted env. 
> 
> With the patch to package.bbclass it can be left as is.
> 
> > > Since I was debugging the code which actually does this shlib magic in 
> > > package.bbclass, I thought it might be useful to prevent this kind of issues 
> > > in the future by skipping symlinks while looking for SONAME/NEEDED in the 
> > > objdump - please see the second patch attached and provide feedback.
> > 
> > But we need to process symlinks to find out package that contains target so that we can create
> > dependency on the package that contains target like in this case we need
> > to create dependency on libvolume-id for libvolume-id-dev because the
> > symlink points to a file provided by libvolume-id
> 
> I'm not sure where this dependency gets built, but I believe it is not done by 
> the package_do_shlibs() code from package.bbclass I'm referring to. This code 
> populates ${STAGING_DIR_HOST}/shlibs, listing .so each pkg provides.
> 
> I guess we need more Core devs to look into this issue to verify the safety of 
> this patch.

Otavio was using patched package.bbclass (as mentioned above) for a few days 
and found it working fine and fixing udev issue for him.

Khem, please let me know if you still disagree with the proposed fix. Or if 
anybody else has any objections, please speak up. Otherwise I'd like to check 
in the fix for the package.bbclass in a day or two. Thanks.

-- 
Denys