Bug 212523
| Summary: | rpmbuild lets x86_64 packages satisfy BR's when building for i386 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Hans de Goede <hdegoede> |
| Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-07-18 19:04:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Hans de Goede
2006-10-27 08:23:46 UTC
There's nothing stopping you from adding arch-specific dependencies to existing dependencies.
Adding
Provides: %{name}.%{_arch}
by overloading the %description section separator to add to every package just like -debuginfo does.
The narrow case you mention -- of having -devel depend on the base.arch package -- might also be
automated, but would be trickier.
And arch-colored dependencies aren't going to succeed any better than %{dist} in Release: "works"
because arch is the wrong attribute to add to dependencies.
All of your suggestion was considered (and discussed with others) before I chose to implement multilib
dependencies based on elf32 and elf64.
"... things aren't that easy ..."
Sorry, I left out " ... -- Requires: %{name}.%{_arch} might also be automated transparently in spec files ..."
in the sentence above.
Hmm,
So you're suggesting that to fix this at the packaging level, I add to foo-devel:
Provides: foo-devel.%{_arch} = %{version}-%{release}
And then to bar:
BuildRequires: foo-devel.%{_arch}
or:
BuildRequires: foo-devel.%{_arch} > 1.0
Thinking about this somemore would it be possible for rpmbuild to check all the
BR's + dependencies to see if they provide any .so 's and then check that they
provide the correct (elf64 vs elf32) so's for the arch which is currently being
build?
Basically yes. If you're really going to attempt a "production" deploy,
I suggest using a name space, i.e. something like
Requires: pkgnamearch(foo) = %{_arch)
rather than
Requires: foo,%{arch}
The reason for using the name space is that it will be easier to verify
dependency closure within that "pkgnamearch(...)" syntax, and the intent
of the dependency implied by the wrapper is clearer, and less likely to collide
with some other dependency.
Note that I think the above is not the right thing to do. however, the existing
dependencies names can easily be used to achieve your requested goal.
rpm-4.4.7 can already verify *runtime* sonames in Provides:. By *runtime*,
I mean an soname from a library not in a package, but rather installed through
other means, like apt, or "make install", or the native vendor install. The *runtime*
dependencies are properly elf32/elf64 colored iirc, certainly can be made so
in an hour if I forgot to do that.
And, for that class of -devel packages that carry a "foo.so" symlink, rpm-4.4.7
generates a dependency for all symlinks on their end-point automagically. That
dependency does not carry elf32/elf64 coloring however.
It should be perfectly obvious that none of the above is possible in rpm-4.4.2:
UPSTREAM
Please add comments to
https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html
|