Dependencies a little excessive?

[Hans de Goede]

seth vidal wrote:
> On Thu, 2006-08-10 at 11:02 -0400, Matthew Miller wrote:
>> On Thu, Aug 10, 2006 at 04:48:41PM +0200, Ralf Ertzinger wrote:
>>>> Are you concerned that there might be a package
>>>> "foobarin86-5.3-1.fc6.x86_64"?
>>>> I guess "." is kind of an unfortunate separator for arch.....
>>> That depends whether that's a shell glob or a regexp :)
>> The pattern is already defined as being a shell glob.
>>
>> Seth, gimmie a hint. What's the issue you're worried about here? :)
>>
> 
> I'm worried about someone legitimately wanting to install both arches
> being stymied by this "feature".
> 

Erm, speaking as a multilib feature, I think an overwelming percentage 
of multilib user wants the suggested feature. Also most yum cmdline 
using multilib user (aka powerusers, who might want both versions) are 
currently used to adding .x86_64 to every package mentioned in a yum 
something command, so if they really want both I'm sure they can figure 
out to add the packagename twice to the cmdline list, once with .x86_64 
appended, and once with .i386 .

I already have been running with both i386 and x86_64 repos of core and 
extras in my /etc/yum.repos.d and have not complained because this is an 
unsupported setup, however the way as things currently work is annoying 
and the suggested feature would make life much easier.

I review quite a few packages and often rpmbuild refuses to build the 
SRPM I'm reviewing because of a missing dep on foo-devel, if I then 
accidently (which still sometimes happens) type:
sudo yum -y install foo-devel
instead of
sudo yum -y install foo-devel.x86_64

I get both versions, which is not what I wanted! I believe the current 
behaviour even though documented is annoying enough to almost warrent 
the title bug and I would love to see the suggested feature.


Notice that this feature should preferably not only be added to the 
cmdline parsing but also to dep resolving.
Sometimes a package will Require /usr/bin/foo, now if /usr/bin/foo is 
not in my system when I'm installing this package and /usr/bin/foo is 
provided by bar then yum will install both the i386 and x86_64 versions 
of bar, which is BAD. This is optimised for the exception that some 
package requires a file and somehow requires that file to be of a 
certain arch, which is crazy, because either the file is an executable, 
in which case either version should work fine (or the Requires is broken 
and the requiering package should be fixed), or it is not an executable 
in which case the versions in the i386 and x86_64 package must be 
indentical otherwise I'll get a file conflict.

Regards,

Hans