[devel] [jbj на JBJ.ORG: Re: RFC: interesting cross compatible arch obsoletes]

Пт Ноя 24 01:18:18 MSK 2000

Кроме всего прочего, здесь упомянута и затронутая недавно тема нескольких
пакетов для разных архитектур.

----- Forwarded message from Jeff Johnson <jbj на JBJ.ORG> -----

Date: Wed, 22 Nov 2000 09:17:23 -0500
From: Jeff Johnson <jbj на JBJ.ORG>
To: rpm-list на redhat.com
Subject: Re: RFC: interesting cross compatible arch obsoletes

On Tue, Nov 21, 2000 at 10:53:16PM -0500, Carlo Marcelo Arenas Belon wrote:
> greetings,
> 
> while playing with the RedHat's 7 up2date agent, i think i have found a
> little bug :
> 
>   http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=21214
> 
> as there is an i686 package that "supercedes" the i386 i got installed, i
> was thinking i would be able to install it as usual.
> 

The word "supercedes" is tricky here, and must be clearly understood in
an rpm context. Rpm configuration has arch/os compatibility tables, rpm
has a concept of machine scoring so that, on an i686, i586 has a lower
score (i.e. low score is preferred) than i386. Arch/os scoring
based on hints from packages is done by the Red Hat installer, for example,
to select the closest matching kernel, and up2date uses machine scoring
as well.

However, what's tricky is that machine scoring is a mechanism that is
provided (but not really used) by rpm. The only use of arch/os hints
from packages by rpm itself is disaster avoidance, like preventing sparc
packages from being installed on i386 platforms. Rpm specifically does
not use arch/os hints when deciding if a package should be upgraded
because a "newer" package is available.

So what's probably happening in up2date is that the machine scoring comes
into play in up2date only when there is a "newer" version available,
not when identical versions of the same package have different arch/os
hints, contrary to your expectation of "supercedes".

> something i had found is that i am unable to rpm -i, or -U this package as
> there is an already installed i386 package with conflicting files.
> 

Yup.

> something like "rpm -e; rpm -i" won't work either as glibc is prerequisite
> for everything i can think of.
> 

Yup.

> i guess, that what should be done is something like "rpm -i --force"
> (--replacepks won't work as there are still conflicting files, so
> --replacefiles would be needed or the --force "short hand")
> 

Yup, --force is needed to re-install a package with the same version.

> this would actually work, but i guess this is something that the average
> joe won't like to do.
> 

Maybe. At the moment, Joe has no choice :-)

> usually, when there is a need to do an "optimized" package all that is
> done is play with the OPTFLAGS and make a --target build.
> 

Yup. "Optimized" is tricky here also, and is pretty much a crock unless
the metric used for comparison is specified. Yes, CFLAGS is different,
but I have yet to hear of significant (i.e. >10%) general (i.e. most packages)
performance gains backed by explicit measurements from diddling CFLAGS for
i[3456]86 platforms.  YMMV, of course.

> obviously the resulting src.rpm is supposed to be the same for --target
> i386, i686 or any other "arch", but every specific arch is built on its
> own compile and they are not "really" built from the same "src.rpm".
> 

The problem of different results from identical src.rpm's runs much deeper
than rpm, straight down through autoconf into the bowels of the build
tools and build system configuration itself, which rpm has not a clue about.
But let's pretend that src.rpm's are the problem ... (no offense intended)

> i think this, would be a design problem on the different arch specific
> generation for RPM and that a better way would be to make the several
> builds as we do subpackages now.
> 

The design rule currently in rpm is
	Only a single arch/os applies for each spec file parse-and-build.
That's basically why, for example, you can't have "noarch" sub-packages, or,
as you suggest, per-arch sub-packages.

> PROS:
> 
> * cross compatible archs obsoletes can be done giving each arch a serial
>   implicitally or explicitally (i386, i586, i686)

Teaching obsoletes (and other dependencies) about arch's is going to be
necessary to handle, for example, sparc/sparc64 and ix86/ia64 compatibility
issues. If you're interested in the work in progress, look for MULTILIB
throughout rpm sources. Caveat emptor: I have no idea whether any of MULTILIB
works at the moment. Thanks to Jakub Jelinek for the patch ...

> * real common src.rpm from "compatible" architectures

For better or worse, src.rpm's are "noarch" (i.e. run on all arches) by
definition, so "compatible" is not going to work.

> * if instructed for build system rpm would make "cross compiling" natural
>   (obviosly a cross compiler would be needed on the build system)

Cross packaging is probably possible with the existing implementation of
rpm, but there has been exactly zero need and/or interest so far.

> * specs would be easier to mantain as all the %ifarch would be taken off

Amen. However, the fiction that src.rpm's are "noarch" must be maintained.

> 
> CONS:
> 
> * specs would be bigger as there would need to be at least one %build
>   section for every supported architecture
> * specs would need to be "rewritten"
> * not too much packages to benefit (actually glibc, gzip and kernel on RH)
> 
> do you thing such a move would be a good idea?
> 

I'll recuse myself here.

Hope the comments help.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj на jbj.org	(jbj на redhat.com)
Chapel Hill, NC

_______________________________________________
Rpm-list mailing list
Rpm-list на redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list

----- End forwarded message -----

Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 232 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20001124/989b8a15/attachment-0001.bin>