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
Attachment:
pgpRMohyGQA6l.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
