[oe] debian.bbclass issues when some package is substring of another

[Martin Jansa]

On Tue, Feb 15, 2011 at 10:19:31AM +0000, Phil Blundell wrote:
> On Tue, 2011-02-15 at 10:15 +0100, Martin Jansa wrote:
> > On Mon, Feb 14, 2011 at 03:27:23PM +0000, Phil Blundell wrote:
> > > b) switch to a two-phase approach where it first renames all the
> > > libraries themselves, then uses some heuristic to match the remaining
> > > packages against the libraries and apply an appropriate renaming to
> > > them.  Probably just matching on longest substring would be good enough
> > > here.
> > > 
> > > I think (b) is probably a better solution although it would be a little
> > > harder to implement.
> > 
> > I'll try (b), but imho you have same problem there (if you have
> > -dev/-dbg for such package names and they are in wrong order, even worse ie:
> > PKG_ncurses-libncurses-dev, libncurses-dev    <= ok
> > PKG_ncurses-libncursesw-dev, libncursesw-dev  <= works only because
> >   ncurses-libncursesw is mapped to libncursesw which is the same like
> >   s/ncurses-libncurses/libncurses
> > 
> > but if you imagine stranger situation with SONAMES which are not
> > substrings of each other in package names which are substrings, like:
> > ncurses-libncurses > libncurses
> > ncurses-libncursesw > libwidecurses
> > 
> > then still
> > PKG_ncurses-libncurses-dev, libncurses-dev    <= ok
> > PKG_ncurses-libncursesw-dev, libncursesw-dev  <= bad, because libwidecurses-dev was expected 
> > 
> > and later you won't find ncurses-libncursesw-dev to replace
> > ncurses-libncursesw with libwidecurses
> 
> I'm not quite sure I understand the difficulty here.

Ah sorry, I didn't read your (b) properly, now I see last sentence about
"longest substring".

But that's mostly what reverse sorted patch does now, isn't it? Longer
patterns are replaced before their shorter substrings (which then
matches only to their proper packages, because longer were already
replaced while handling longer pattern and "normally" doesn't match
anymore).

Regards,

> If I understand right you're talking about two output packages,
> "ncurses" and "ncursesw", which contain sonames "libncurses.so.5" and
> "libwidecurses.so.5", right?  In that case, during the first phase you'd
> get:
> 
> PKG_ncurses = "libncurses5"
> PKG_ncursesw = "libwidecurses5"
> 
> and a dictionary of renames performed which would look a bit like:
> 
> ncurses: { pkgname: libncurses5, devname: libncurses }
> ncursesw: { pkgname: libwidecurses5, devname: libwidecurses }
> 
> which is all expected.  Then, during the second phase, you'd consider
> the other packages like ncurses-dev and ncursesw-dev.  In this case, the
> longest prefix match for ncurses-dev in the dictionary is "ncurses", so
> it'd get renamed to libncurses-dev.  The longest matching prefix for
> ncursesw-dev in the dictionary is "ncursesw", so it'd get renamed to
> libwidecurses-dev.  That all seems like it should work out fine.
> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110215/b3da6310/attachment-0002.sig>