All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Fix udev pulling in libvolume-id-dev
Date: Fri, 13 Mar 2009 21:08:27 -0400	[thread overview]
Message-ID: <20090314010827.GA29178@denix.org> (raw)
In-Reply-To: <gko0tu$hel$1@ger.gmane.org>

On Thu, Jan 15, 2009 at 07:57:02PM +0100, Koen Kooi wrote:
> On 15-01-09 19:53, Khem Raj wrote:
>> On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi<k.kooi@student.utwente.nl>  
>> wrote:
>>> On 15-01-09 08:41, Khem Raj wrote:
>>>> On (15/01/09 07:56), Koen Kooi wrote:
>>>>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>>>>
>>>>>> 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...
>>>>> That's the intended behaviours, since installing the packages will have
>>>>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>>>>> want to patch every package to use relative symlinks.
>>>> We would use -dev packages on staged area normally to compile other apps
>>>> depending on a given packge if we do not fix the symlink I think it will
>>>> try to link to wrong library.
>>> We don't use the -dev packages to populate staging :) I keep trying to
>>> convince Richard that we should use them, but he keeps coming up with 
>>> good
>>> reasons not to do so :)
>>
>> Hmm then why do we generate them ?. We do not need these packages on
>> target unless we switch to
>> native development on target.
>
> SDks and as you say native development (which is getting quite popular with 
> the beagleboard folks).

Ok, I'm bringing up this old topic, because as was correctly stated, SKDs use 
-dev packages and if we don't fix the symlink pointing to /lib/libvolume.so.0, 
it breaks those SDKs. There is also another side-effect - libvolume-id-dev.ipk 
misses the automatic dependency on libvolume-id0.ipk so the SDK cannot just 
refer to the -dev package and expect the actual library to be installed. In 
that case only the broken link gets installed...

So, if nobody objects, I'm going to apply my first patch from this thread 
against the udev recipe, fixing .so symlink to be relative.

-- 
Denys



  reply	other threads:[~2009-03-14  1:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15  6:14 [RFC] Fix udev pulling in libvolume-id-dev Denys Dmytriyenko
2009-01-15  6:56 ` Koen Kooi
2009-01-15  7:41   ` Khem Raj
2009-01-15 11:10     ` Koen Kooi
2009-01-15 18:53       ` Khem Raj
2009-01-15 18:57         ` Koen Kooi
2009-03-14  1:08           ` Denys Dmytriyenko [this message]
2009-01-15 19:20         ` Tom Rini
2009-01-15 19:41           ` Koen Kooi
2009-01-15 15:58   ` Denys Dmytriyenko
2009-01-15  7:37 ` Khem Raj
2009-01-15 15:51   ` Denys Dmytriyenko
2009-01-18  4:18     ` Denys Dmytriyenko
2009-01-19  0:56       ` Otavio Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090314010827.GA29178@denix.org \
    --to=denis@denix.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.