Created attachment 72966 [details]
zmd-backend log

There used to be a naming convention to add '-32bit' to the end of ix86 package name in case there's a package with same name for x86_64 arch. Is this still true? If yes, then this bug is invalid. If not, then we need to discuss what to do in that case. Which package should get installed? The x86_64 version? What if one of these is already installed? What if I acctually want i586 version? Both? Can zypp's resolver handle that? I know libredcarpet's can not.

My personal opinion is that we should install both (like yum does, for example) but adding new functionality to resolvers doesn't sound very appealing after beta 8.

We only add -32bit for library packages.  In those cases you have a:
libxy-32bit.x86_64.rpm

But with normal packages the setup is correct - and libzypp handles this fine, it installs the i586 gnokii package and not the x86-64 one.

It should only install one package not both, you get otherwise file conflicts.

I'm really confused now. First, you open a bug report with a summary 
"rug installs i586 binary instead of x86_64"

and then you say

"But with normal packages the setup is correct - and libzypp handles this fine,
it installs the i586 gnokii package and not the x86-64 one."

The last sentence was wrong.  During a new install with YaST/libzypp I will get the x86-64 package as desired and *not* the i586 one.  But accessing the same catalog with rug I get an i586 binary.

Ok. So now I'm confused about the output from the inital description. First, 'rug search' shows none of the gnokii versions is installed. Then, the following command, 'rug info' shows it is installed. Did you do something in between? How did the gnokii suddenly got installed?

Apart from all that, I just committed some changes for rug with the following commit message:

"       Implement more advanced format for 'install'
	command. It is now possible to specify resolvables in the following
	formats:

	name
	name.arch
	name-version
	name-version-release
	name-version-release.arch
	name-epoch:version-release.arch
	epoch:name-version-release.arch
	/path/to/local/package.rpm
"

So it's possible to specify which arch you need.

I missed to show the "rug in gnokii" line in between :-(

That helps a lot!

Still what happens on my x86_64 system if I do the following?

rug in gnokii

It should install the gnokii.x86_64.rpm (if one exists).

The logic is to take all the specified constraints from the command line (catalog, allow unsubscribed, name, version, release, epoch, arch), get a list of matching packages and filter out all older versions of every name,arch pair. So in short, if there's multiple archs of the same package available it tries to install both.

Adding multiple packages is not the right solution.

Why is it better to install the 64 bit version? If there's also a 32 bit package for the same thing, I'd think it's there because it's needed. Why would we want to guess if we have no information to base the guess? So we don't, if the packages have file conflicts, the resolver tells us. User gets the error and has to specify which one is wanted.

Anyway, lowering the severity, there is at least a workaround, either way to following discussions goes.

No, it's not there because we have a tree that is multiarch and contains rpms for all possible architectures!

Oh, right. There's one shared repository that provides packages for all architectures, including 64 bit architectures? On 64 bit systems, people should have only 64 bit packages unless they have '-32bit' in the name?

I typoed the last sentence, sorry. What I meant was:

On 64 bit systems, people should have only 64 bit packages unless package name contains '-32bit'?

Adding kkaempf to the cc as an fyi.

If there is a package available both as x86 and x86-64 version, the x86-64 should be installed.

If there's only a x86 version that version should get installed.

But how do you know that package is meant to be installed on 64 bit machine? When we have all packages for all architectures in one metadata, how do you make a difference whether a package is meant to be installed only on i386 platform (depends on foo) or whether it's meant to be installed on 64 bit machine (depends on foo-32bit)?

It doesn't look like this discussion is going anywhere here, I'll start a discussion on the mailing list.

With multi-arch catalogs, you can install i686(i586,...) and x86_64 machines from the same package repository. zypp does two things to accomplish that:
- filter out incompatible architectures (filter out x86_64 on i686 systems)
- if multiple providers are present (i.e. a i586 and a x86_64 system), choose the 'best' one.


Tambet, zmd needs knowledge about
- the target systems architecture
- the architecture compatibility list
- the architecture score (iirc, libredcarpet calls it 'score')

libzypp has all this knowledge.
Should we export this to a (new) sqlite table so libzypp and zmd have the same view on architecture, compatiblity, and score ?

zmd has that knowledge, thank you.

From this specific example, it looks like the gnokii.i586 is never meant to be installed on x86_64. If there were a reason to have that package available for x86_64, then it would have -32bit in the name. Yes, you can run 32 bit binaries on x86_64, but you can't install random 32 bit rpms which are built for 32 bit platform only. This would be possible only if there's always a 64 bit and a 32 bit version of everything and these two versions never conflict with each other.

Since we have both gnokii.i586 and gnokii.x86_64, gnokii.i586 should not get installed by default on x86_64.

but for other programs like OpenOfficeOrg we have only an i586 package, so OOo.i586 should get installed on x86_64.

Chris to review code/solution with James and Tambet prior to checkin.

Is this still open - or fixed with the latest submissions?

This is fixed now.  It will be available in autobuild shortly.

r26462

Verified with SLES10 RC2 x86_64:

- deinstalled nautilus. reinstalled with rug -> arch x86_64 was chosen among i586
- installed OpenOffice (from Stable) -> arch i586 was chosen