i386 packages sneaking in on x86_64 platform (was: lm_sensors in FC4-updates for x86_64 twice?)

[Axel Thimm]

On Sun, Nov 27, 2005 at 01:24:41PM +0000, Willem Riede wrote:
> On 11/27/2005 06:38:28 AM, Axel Thimm wrote:
> >On Sat, Nov 26, 2005 at 05:33:16PM -0500, seth vidal wrote:
> >> On Sat, 2005-11-26 at 22:53 +0100, Florian La Roche wrote:
> >> > > no, I don't want to hear any bitching and moaning about this,
> >> > > that's how it is.
> >> >
> >> > At some point we should change this to only pull in as few
> >> > packages as really needed, but that also comes with quite some
> >> > calculation cost.
> >>
> >> why isn't the way it's currently being done correct? We've gone
> >> round and round on this and its always come down to how to handle
> >> globs of commands.
> >
> >Sometimes less is more. Why should a system be polluted with i386
> >packages, if the user does not need them?
> 
> Indeed. But that should be considered by the repo creator.

IMHO not. The repo creator should be offering choice, thus maximizing
the offered package ensemble, and not enforce a policy. The policy
should be at the user's control, e.g. to prune multilib away from an
x86_64 system and not seeing the i386 packages sneak in by way of the
depsolver.

> If there is no need for a i386 variant of package X then X.i386
> should not be in the x86_64 repo.

If there is a use for some users (even for a non-negligible minority
of users) for a i386 campatibility package then the repo maintainer
needs to add it. But that doesn't mean that every user has to get it
pasted into his system.

Good solutions in dependecy calculations are such that offer the
smallest possible solution. Otherwise "install all" is also a valid
solution for any soluble depsolver problem :)

In fact the end user should not notice what arch he is using. If some
application is i386 only and requires some i386 packages, then the
depsolver should get the compatibility packages, otherwise not.

It's different for a developer, who knows that he wants foo.i386, even
if there is a foo.x86_64. Since developers (should) know how to deal
with selecting packages upon arch, while end users should not need to,
the default should be to not install tuples of packages for all
supported arches, but to find the minimal solution.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/6080ff41/attachment.sig>