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.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
