[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RPM roadmapping

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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]