Stefan Dirsch told me that in openSUSE 10.1, a package "foo-32bit" was
always installed by default if the package "foo" was installed by
default.

Apparently this is no longer the case. Why not?

scim-32bit and scim-qtimm-32bit are necessary to use scim in 32bit
applications like firefox or OpenOffice.

Therefore I think these packages should always be installed by default
on a 64bit system if the 64bit parent packages scim and scim-qtimm are
installed by default.

How to achieve that?

One possibility would be to always install foo-32bit packages if foo is installed.

Another possibility would be to make scim-32bit and scim-qtimm-32bit provide
some locales. Currently:

mfabian@magellan:~$ rpm -q --queryformat "%{provides}\n" scim
locale(ja;ko;zh)
mfabian@magellan:~$ rpm -q --queryformat "%{provides}\n" scim-32bit
aaa-frontend-setup.so
mfabian@magellan:~$ rpm -q --queryformat "%{provides}\n" scim-qtimm
locale(qt3:ja;ko;zh)
mfabian@magellan:~$ rpm -q --queryformat "%{provides}\n" scim-qtimm-32bit
libqscim.so
mfabian@magellan:~$ 

I.e. the parent packages are installed by default for CJK because they
provide locale ja;ko;zh. But as the -32bit packages don't provide
these locales and there is no other mechanism which causes them to be
installed, they are never installed at all by default.

This bug was found by Zhe Su in openSUSE 10.2. But as openSUSE 10.2 is
already released I guess we cannot fix this for openSUSE 10.2 anymore,
therefore I entered this as a bug against openSUSE 10.3.

Assign to Andreas Jaeger <aj@novell.com> because he takes care of the patterns.

As for comment #1, I hope this is wrong for 10.1. Always installing the -32bit packages seems to be a bad idea to me.

(In reply to comment #5)
> As for comment #1, I hope this is wrong for 10.1. Always installing
> the -32bit packages seems to be a bad idea to me.
We did this since we began to ship x86_64. I did never hear a single complain about this.

Are you sure? I don't think we ever did this. Why would there be a 32bit packages in the selections if that was true? Or are you talking about whether the 32bit packages are in the patterns? That's a different issue.

Mike and me are talking about patterns - formerly known as selections.

Ok, so comment #1 is just misleading.

Just talked with Klaus.  We want a generic solution for this for 10.3 and he's going to design it.

We already have parts of the solution, call "conjunctions" and described at
http://en.opensuse.org/Software_Management/Dependencies/Conjunctions

The basic functionality is identical to how locales (comment #2) are handled: Conditional dependencies.

For locales, the package says "if this parent package and this locale are installed, install me also". The same semantics should be applicable to -32bit packages, i.e. expressing "if this parent package is installed and a 32 bit runtime environment is requested, install me also."

We could handle this in patterns already. However, this is the wrong place as it needs adoption of the pattern every time a -32bit package is introduced. This simply doesn't work for 3rd party -32bit packages.

More flexible conditional dependencies are a major feature for the next generation of libzypp (targeted for 10.3). So please be patient ;-)

If it's going to be generic, please make it configurable (i.e. some users don't want all 32bit libs installed, just the ones dragged in by library dependencies).

The biggest problem I see is that rpm has no way to tag dependencies with an architecture. Real life has two types of dependencies:
1) "feature" dep: I want this program/feature to work
2) "extension" dep: I am an extension for a program/lib with a specific architecture.

As an example, our perl modules have "Require: perl = <version>", but in reality it is perl with a specific version *and architecture*.
Another example are -devel and -debuginfo packages, they also need the exact architecture.

Yet another example: My brother upgraded a x86_64 host from 10.0 to 10.2, 10.0 has a i386 only Firefix. He then did an YOU update that installed the "MozillaFirefox-translations" translations package, but with architecture x86_64! The package was not installed before, so libzypp happily selected the x86_64 architecture.

Stano, what's the status on this bug?

The generic solution was not done for 10.3.

Klaus, any proposed workaround?

No, such functionalty is not covered by the current dependency solver.

The easiest workaround is probably providing per-architecture repositories.

Revisit in preparation of Code11

Adding Peng Wu <pwu@novell.com> to CC: because he encountered problems
with input methods in Firefox because scim-bridge-gtk-32bit wasn’t
installed by default.

Micheal, how to handle this in sat-solver ?

Dunno, it's more about specifying dependencies in rpm. The sat solver is not an issue.

rpm5 uses name.arch to specify architecture in dependencies. (see rpm5/lib/rpmns.c in rpm5 source code).
The arch part is compared against this list:
    "i386", "i486", "i586", "i686", "athlon", "pentium3", "pentium4",
    "x86_64", "amd64", "ia32e",
    "alpha", "alphaev5", "alphaev56", "alphapca56", "alphaev6", "alphaev67",
    "sparc", "sun4", "sun4m", "sun4c", "sun4d", "sparcv8",
    "sparcv9", "sparcv9b", "sparcv9v", "sparcv9v2",
    "sparc64", "sun4u", "sparc64v",
    "mips", "mipsel", "IP",
    "ppc", "ppciseries", "ppcpseries",
    "ppc64", "ppc64iseries", "ppc64pseries",
    "m68k",
    "rs6000",
    "ia64",
    "armv3l", "armv4b", "armv4l",
    "armv5teb", "armv5tel", "armv5tejl",
    "armv6l",
    "s390", "i370", "s390x",
    "sh", "sh3", "sh4", "sh4a", "xtensa",
    "noarch", "fat",

If its not in this list, ".arch" is considered part of the name.

Back to rpm and sat-solver maintainer to support this notation in both tools.

This bug is actually about two things:
- having the 32bit packages in a pattern
- supporting .arch dependencies.

I don't know if we have a solution for the first topic.
Regarding the second, we can't support .arch deps for 11.0, as this must be supported by rpm.

bug #382523 might be related to this bug.

Is this solved in current versions 11.3 and 11.4? 

(just shaking old bugs during openSUSE Bug Day)

for other such problems we add recommends to the -32bit package. Because it's not normally needed.

close as noresponse