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

Re: RPM roadmapping



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 -


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