RPM roadmapping

[Panu Matilainen]

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 -