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).
I think this bears mentioning in
https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires
And I think the example there needs to add the architecture to be correct.
Braden McDaniel braden@endoframe.com 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.
regards, tom lane
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com 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?
Or maybe I'm misunderstanding what you think the bug is...?
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
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?
Why would it need to? I should only have to require "foo", I should not have to know whether foo comes in arch-specific or arch-independent form. It should be up to the buildsystem to acquire the version that is most appropriate for the target arch being built.
regards, tom lane
On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
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?
Why would it need to?
Because there's no reason to specify the architecture if it truly doesn't matter. For instance, if my package runs an executable, I probably don't care whether the executable was built for i686 or x86_64. On the other hand, if my package dlopen's a library, I probably do care.
I should only have to require "foo", I should not have to know whether foo comes in arch-specific or arch-independent form.
It will always *come* in an arch-specific form--which is why it's important to specify the right one when it matters.
It should be up to the buildsystem to acquire the version that is most appropriate for the target arch being built.
If you're using "Requires", the build system is most likely irrelevant. "Requires" tends to be for things that are resolved at run time.
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
If it's a bug, then how do you propose a specfile should articulate a "Requires" that *can* be satisfied by any architecture?
Why would it need to?
Because there's no reason to specify the architecture if it truly doesn't matter.
Indeed.
For instance, if my package runs an executable, I probably don't care whether the executable was built for i686 or x86_64. On the other hand, if my package dlopen's a library, I probably do care.
Well, for separate executables you shouldn't have to care. For ordinary library bindings, the appropriate require is generated by RPM and the packager need not worry about it. I concede that dlopen'd libraries might need arch-specific Requires, but that's hardly such a common case as to motivate a recommendation that Requires should "usually" be arch-specific.
regards, tom lane
On Tue, 2009-09-15 at 22:32 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
If it's a bug, then how do you propose a specfile should articulate a "Requires" that *can* be satisfied by any architecture?
Why would it need to?
Because there's no reason to specify the architecture if it truly doesn't matter.
Indeed.
For instance, if my package runs an executable, I probably don't care whether the executable was built for i686 or x86_64. On the other hand, if my package dlopen's a library, I probably do care.
Well, for separate executables you shouldn't have to care. For ordinary library bindings, the appropriate require is generated by RPM and the packager need not worry about it. I concede that dlopen'd libraries might need arch-specific Requires, but that's hardly such a common case as to motivate a recommendation that Requires should "usually" be arch-specific.
It's a sufficiently common case that the packaging guidelines use it as an example for explicit Requires.
Is there a more common case for explicit Requires (used by non-noarch packages) that I'm overlooking?
On Tue, 2009-09-15 at 23:36 -0400, Braden McDaniel wrote:
On Tue, 2009-09-15 at 22:32 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com writes:
If it's a bug, then how do you propose a specfile should articulate a "Requires" that *can* be satisfied by any architecture?
Why would it need to?
Because there's no reason to specify the architecture if it truly doesn't matter.
Indeed.
For instance, if my package runs an executable, I probably don't care whether the executable was built for i686 or x86_64. On the other hand, if my package dlopen's a library, I probably do care.
Well, for separate executables you shouldn't have to care. For ordinary library bindings, the appropriate require is generated by RPM and the packager need not worry about it. I concede that dlopen'd libraries might need arch-specific Requires, but that's hardly such a common case as to motivate a recommendation that Requires should "usually" be arch-specific.
It's a sufficiently common case that the packaging guidelines use it as an example for explicit Requires.
Is there a more common case for explicit Requires (used by non-noarch packages) that I'm overlooking?
... And dlopen'd libraries aren't the only cases that merit an arch-specific Require. So do Requires for -devel packages. And a subpackage's Require for its main package should be arch-specific, too.
Tom Lane tgl@redhat.com writes:
If it's a bug, then how do you propose a specfile should articulate a "Requires" that *can* be satisfied by any architecture?
Why would it need to?
dietlibc needs this. There are the arch specific libs in -devel and the common 'diet' program in 'dietlibc'. E.g. 'dietlibc-devel' for x86_64 and i386 can be used both with 'dietlibc' for x86_64 and for i386.
Enrico
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com 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
Enrico
On Wed, 2009-09-16 at 10:06 +0200, Enrico Scholz wrote:
Braden McDaniel braden@endoframe.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com 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.
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Braden McDaniel braden@endoframe.com 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.
Well, if it's a bug then the entire multilib approach is a bug ;)
Jon.
Jon Masters jcm@redhat.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Surely this is a bug, not something that every single specfile must work around.
Well, if it's a bug then the entire multilib approach is a bug ;)
I think that's widely agreed ;-). Multilib is a crock that is meant to sort of work for some common cases. The cases that Braden seems to be worried about, like version skew between different installed arches of the same package, are not something multilib was ever expected to be able to handle gracefully.
regards, tom lane
On Tue, 15 Sep 2009, Tom Lane wrote:
Jon Masters jcm@redhat.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Surely this is a bug, not something that every single specfile must work around.
Well, if it's a bug then the entire multilib approach is a bug ;)
I think that's widely agreed ;-). Multilib is a crock that is meant to sort of work for some common cases. The cases that Braden seems to be worried about, like version skew between different installed arches of the same package, are not something multilib was ever expected to be able to handle gracefully.
and yet just the other day I was hit up about making sure we install both versions (i386 and x86_64) of a set of libraries on any install for a customer using a fedora-derived distribution.
-sv
On Tue, 2009-09-15 at 22:39 -0400, Tom Lane wrote:
Jon Masters jcm@redhat.com writes:
On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote:
Surely this is a bug, not something that every single specfile must work around.
Well, if it's a bug then the entire multilib approach is a bug ;)
I think that's widely agreed ;-). Multilib is a crock that is meant to sort of work for some common cases. The cases that Braden seems to be worried about, like version skew between different installed arches of the same package, are not something multilib was ever expected to be able to handle gracefully.
Actually, what I'm worried about is, "yum pulls in a bunch of i686 packages as dependencies that won't work when (for some reason) it can't find the x86_64 ones that it really needs".
I don't think that's acceptable behavior.
packaging@lists.fedoraproject.org
-
Braden McDaniel -
Enrico Scholz -
Jon Masters -
Seth Vidal -
Tom Lane