[OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code

[Phil Blundell]

On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> 
> > It does look a bit weird.  That code was introduced in 561d8754,
> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> > original code from glibc-package.bbclass did:
> > 
> >       def output_locale_binary_rdepends(name, pkgname, locale, encoding):
> >               m = re.match("(.*)\.(.*)", name)
> >               if m:
> >                       glibc_name = "%s.%s" % (m.group(1), m.group(2).lower().replace("-",""))
> >               else:
> >                       glibc_name = name
> >               bb.data.setVar('RDEPENDS_%s' % pkgname, legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> > 
> > ... i.e. it was using the "." separator both for splitting and joining,
> > which seems reasonable.  But somehow when it showed up in
> > libc-package.bbclass it had gotten transmogrified so that it split on
> > "_" but joined with "." as you showed below.  That seems bogus to me.
> 
> There is something funky going on if you use cross-localedef instead of on-target localedef and it looks like this is one of the reasons. I can respin the patch in different split formats if people want. But most of all I'd like to know what is going on :)

Well, the original purpose of that code (when it split on dots) was to
squash hyphens in encoding names.  That is, it transforms "en-US.utf-8"
to "en-US.utf8", on the grounds that the dash isn't significant there
and might be confusing with all the other dashes that go on in the
package name.

I don't know why cross-localdef would be doing anything different to the
on-target one.  Can you expand on what exactly is the funky behaviour
you see?

p.