On Wed, 2009-09-16 at 10:06 +0200, Enrico Scholz wrote: > Braden McDaniel <braden@xxxxxxxxxxxxx> writes: > > > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > >> Braden McDaniel <braden@xxxxxxxxxxxxx> writes: > >> > Since apparently a requirement for "foo" can be satisfied by any > >> > available architecture for which a "foo" is available, "Requires" that > >> > do not specify the architecture are unsafe for multilib systems (unless > >> > the dependency really can be satisfied by any architecture--which does > >> > not strike me as the most common case). > >> > >> Surely this is a bug, not something that every single specfile must > >> work around. > > > > If it's a bug, then how do you propose a specfile should articulate a > > "Requires" that *can* be satisfied by any architecture? > > Can be solved with virtual provides (which should not be tied to an > architecture): > > > | Provides: program(%name) = %version-%release > | > | %package devel > | Requires: program(%name) = %version-%release So you'd want to change the meaning of an unadorned package name in Requires to imply the same architecture as the same package build? I'm a little skeptical that will go over well. Also, the approach you suggest requires buy-in from the dependency (to provide the virtual package name) and the consequence is a substantial expansion of the set of virtual package names. -- Braden McDaniel <braden@xxxxxxxxxxxxx> -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
