[yocto] A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

On Wed, 2012-04-18 at 08:38 +0800, Xu, Dongxiao wrote:
> On Tue, 2012-04-17 at 10:35 -0500, Mark Hatle wrote:
> > On 4/16/12 8:01 PM, Xu, Dongxiao wrote:
> > > Hi,
> > >
> > > I am testing beagleboard with RPM, and there is a question I am confused
> > > with that PACKAGE_ARCH is renamed for certain packages. For example the
> > > "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> > > in RPM file, the arch is renamed to "armv7a", see
> > > "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> > > "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
> > >
> > > Could anybody give hint on this?
> > >
> > > Thanks,
> > > Dongxiao
> > >
> > 
> > I've not seen that happen before.  Can you checked if an 
> > acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
> > it never generated?
> 
> No, there is no acl-xxx.armv7a-vfp-neon.rpm, only acl-xxx.armv7a.rpm
> created.

Just looked at this issue with Lianhao, and we got some clues.

It seems that we don't allow '-' exists in architecture label within
RPM. Here for the beagleboard case, we use the parameter as:

rpm ... --target "armv7a-vfp-neon-poky-linux"

I think the RPM internal strips all the contents after the first '-' and
use "armv7a" as the architecture label.

Similar is the multilib case, we can see from the code that, we use
'lib64_qemux86' instead of 'lib64-qemux86' as the architecture label.

If our thoughts are right, I think we need a fix for that before 1.2
release?

Thanks,
Dongxiao

> 
> Actually I think this issue does exist since our 1.1 release, you can
> have a look at the package repo:
> 
> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/rpm/armv7a-vfp-neon/
> 
> The directory is named as "armv7a-vfp-neon", however all the packages
> under the directory are of "armv7a" architecture.
> 
> While see the ipk part:
> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/ipk/armv7a-vfp-neon/
> The directory name and rpm architecture name are the same.
> 
> Thanks,
> Dongxiao
> 
> > 
> > As another user mentioned, it is possible for a package to say it wants a 
> > specific arch type, but if it did -- it should be consistent between packaging 
> > systems.
> > 
> > --Mark
>