RPM roadmapping

Panu Matilainen pmatilai at redhat.com
Tue Aug 7 12:01:55 UTC 2007


On Thu, 2 Aug 2007, Lennert Buytenhek wrote:

> On Thu, Aug 02, 2007 at 12:42:27PM +0300, 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
>>> what about being able to say foo.i?86
>>
>> What about foo.athlon which is also a 32bit arch?
>
> Can you match against the canonical arch, i.e. %{_arch}?
>
> On ARM, we have armv3l, armv4l, armv4tl, armv5tl, armv5tel,
> armv5tejl, armv6l, et cetera, but %{_arch} is always just 'arm'.

That'd probably work for i386 and x86_64 but I wonder how ppc vs ppc64 
behaves with %{_arch} ?

My dislike with that is it overloads the meaning of arch. Consider a 
package for which i386 and i686 package is available, both would then 
provide foo.i386. Confusing and problematic, at least in the cases where 
you want (additional) dependency on %{_target_cpu}.

 	- Panu -




More information about the fedora-devel-list mailing list