Re: zypper and poky architectures

[Qing He <qing.he@intel.com>]

On Thu, 2010-10-21 at 23:18 +0800, Mark Hatle wrote:
> On 10/21/10 3:33 AM, Qing He wrote:
> >    1. what uses for independent packages is called "noarch", "all" is not
> >       recognized, something depends on update-rc.d won't be installed
> >       because of missing dependency
> 
> We can certainly look into translating "all" to "noarch" post 0.9.  That might 
> make it easier for people coming from the RPM world, to understand what is in 
> the package.
>
> >    1. rename *.all.rpm to *.noarch.rpm
> 
> We can certainly do this easily.

If noarch is universally used in RPM word, I think we should use it.

> 
> >    2. the arch automatic detection system uses "uname -m", thus producing
> >       armv5tejl, which can only be resolved as armv5tel, conflicting with
> >       "armv5te" in rpm
> 
> This is a bug in Zypper.  The machine names should come from somewhere other 
> then uname -m.  (The value of uname -m is very much ia32 specific for the most 
> part.. other architectures have way too many possible namings for it to be 
> useful.)   There is a line in "/etc/rpm/platform" that contains the name of Poky 
> architecture.  This file should be referenced (instead of -m) for all cases.
>
> >    3. enhance zypper arch module, make the addition more flexible,
> >       allowing arch alias (e.g. armv5te = armv5tel = armel = arm)
> 
> Zypper should read the rpm platform file.

Sounds reasonable. After all, zypper is only intended to be a frontend
utility to the lower end package tool. Then we won't need to worry about
alias and different naming, and this detaches zypper from hardware.

> 
> >    3. many archs are missing in zypper, like mips, armeb, etc.
> >    4. there is no concept of machine-dependent packages (task-base) in
> >       zypper, although we can work around.
> 
> Generally speaking, this is true of most RPM installations.  However, within RPM 
> itself.. there really isn't any concept of "arch" anymore.. They're really only 
> used for grouping and ordering.  So Zypper may need to be updated to query the 
> arch of a package and use it for it's various operations.
> 
> >    2. removing the concept of machine-dependent packages, change all
> >       *.qemuarm.rpm to *.armv5te.rpm
> 
> I'm a bit worried about doing this, as we'll end up with (potentially) 
> incompatible packages with exactly the same name and versions...  Perhaps we 
> need to think about embedding the machine type into the name of the packages 
> instead?

Thanks for the info. If we are going for dynamic platform specs, it
doesn't really matter whether we have things like qemuarm or not, does it?

> 
> 
> > That would be some work to do, maybe 1.0 is a good time to get zypper
> > and package upgrade truely working.
> 
> Yes, we also need to get multi-arch as well.. (i.e. 32-bit and 64-bit at the 
> same time) working.  I'm guessing there will be some Zypper interactions there 
> as well.
> 

I don't really have ideas how this is done. I think on debian this is
actually avoided and i386 packages are repackaged as lib32xxx for x86_64
platform.

Thanks,
Qing