All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: e2fsprogs-libs build failure analysis
Date: Tue, 14 Jul 2009 18:16:10 -0400	[thread overview]
Message-ID: <20090714221610.GA31558@denix.org> (raw)
In-Reply-To: <20090714203551.GA8460@gmail.com>

On Tue, Jul 14, 2009 at 01:35:51PM -0700, Khem Raj wrote:
> On (14/07/09 20:47), Richard Purdie wrote:
> > Hi,
> > 
> > On Sun, 2009-07-12 at 23:57 -0400, Denys Dmytriyenko wrote:
> > > On Sun, Jul 12, 2009 at 01:34:34PM -0700, Khem Raj wrote:
> > > > Like many others I was also getting this problem reported on this mailing list in past 
> > > > 
> > > > http://article.gmane.org/gmane.comp.handhelds.openembedded/24445/match=e2fsprogs+libs
> > > > 
> > > > I looked a bit into this and the problem is that PN gets overwritten when 
> > > > do_package_write_ipk -> read_subpackage_metadata 
> > >
> > > Have you seen this thread several months ago with the same analysis:
> > > http://thread.gmane.org/gmane.comp.handhelds.openembedded/22376/focus=22556
> > > 
> > > As I said before, pkgdata/runtime handling needs fixing - if multiple recipes 
> > > (or even target vs. native/sdk of the same package, like it was with curl) 
> > > provide the identically named .so library (libblkid in this case) during the 
> > > build, there may be a conflict in the pkgdata/runtime files.
> > > 
> > > What are the pkgdata files are used for ultimately? Do they need to contain 
> > > PN/PV/PR? That was introduced by the commit mentioned in the thread above... 
> > > Should it be reverted?
> > > 
> > > Lets ask Richard - he made this change in Poky, maybe he has a better fix for 
> > > it... :)
> > 
> > The real problem here is two packages providing the same library. This
> > is actually a critical error and means your distro is screwed unless
> > handled very carefully. Rather than hacking around the problem, I'd much
> > rather we detect and abort in this case and warn the user something is
> > about to break and that any package feeds will need careful attention.
> 
> yeah I would agree on both counts.

Sorry, this might be a stupid question, but can update-alternatives handle 
libraries? Would that solve the issue of multiple packages providing the same 
library?

-- 
Denys



      reply	other threads:[~2009-07-14 22:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-12 20:34 e2fsprogs-libs build failure analysis Khem Raj
2009-07-13  3:57 ` Denys Dmytriyenko
2009-07-14 19:47   ` Richard Purdie
2009-07-14 20:33     ` Koen Kooi
2009-07-14 21:13       ` Leon Woestenberg
2009-07-15  1:43         ` Elvis Dowson
2009-07-15  7:10         ` Koen Kooi
2009-07-14 20:35     ` Khem Raj
2009-07-14 22:16       ` Denys Dmytriyenko [this message]

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=20090714221610.GA31558@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.