On Fri, 27 Jul 2007, dragoran wrote:
Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
arch requires and provides ... to end the endless multilib discussions ;)
should be automatic until the packager say Requires: foo.arch
I wish it was that simple...
Sure, being able to say "Requires: foo.arch = version-release" would help
in many cases, but it does not *solve* the multilib problems.
A big offender here is the x86 architecture with i386, i486 ... etc
subarchitectures. While most packages are i386 there, the assumed
--
Requires: <name>.%{_target_cpu} = <version>-<release>
BuildRequires: <name>.%{_target_cpu} >= ...
--
gets into trouble when the subarch's don't match between packages (eg i386
vs i686 - just look at glibc vs glibc-common). Instead, you'd want to
match within 32bit vs 64bit (or independent, basically noarch) bitness of
the package (rpm uses the term "color" for this) and have the depsolver
sort out package with the best arch within that "color".
I'm starting to get tempted to have rpmbuild automatically slap in the
equivalent of
Provides: %{name}.%{color} = %{epoch}:%{version}-%{release}
..where %{color} gets expanded to 32bit, 64bit or none, based on the
highest color present in the package being built. I don't particularly
like the term "color" there, and also "none" for "noarch" is not good,
but I don't want it to be "noarch" to avoid mixing with %{arch} when it's
a different concept. Better suggestions welcome...
RPM itself could parse requires on %{name}.%{color} without having the
explicit provides added, but the color information is not present in the
repository metadata (at least currently) so depsolvers would need to be
taught about it separately, and second-guess the color based on the
package %arch.. probably just easier to slap in the explicit provide,
which can be then required by packages needing it.
BTW, there are cases where the dependency on the exact %{_target_cpu}
would be proper (look at libbeagle vs libbeagle-devel), but those are so
rare that I think they are sufficiently covered by manually adding
provides-requires pair on %{name}.%{_target_cpu}
It would be nice to automate all this, but it gets damn hairy. If you have
a manual "Requires: foo" or "BuildRequires: foo", how's rpm supposed to
know whether foo is a package that
a) contains a utility the build needs, never mind the arch
b) contains a dlopen()'ed library, arch very much matters, to the point of
subarch's even
c) is a -devel package's dependency on another -devel package, color
matters (must match or be a noarch)
From there we get to the chicken-and-egg problem of srpms and spec files.
The arch and color can only be determined on spec evaluation, but
src.rpm's are used to deliver the specs, duh... (this problem already
exists of course, "rpmbuild -bs foo.spec" can deliver different results
depending on which are it was run on due to spec conditionals)
And so on. Multilib is so lovely...
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
