Bug#469035: libc6-i386: include mutiarch ld.conf from i386
Javier Serrano Polo a écrit :
> El dl 12 de 05 de 2008 a les 00:26 +0200, en/na Aurelien Jarno va
> escriure:
>> As already explained, the main problem is that you are calling
>> "multiarch" something that is really different from the original
>> concept. If you had read the proposed links you would have noticed that.
>
> Multiarch: Running packages for a different architecture on your own
> one. Furthermore, being able to build such packages on your own
> architecture.
>
> What's wrong with my concept?
This is just plain FUD here. In this sentence, I didn't criticize your
concept, just the fact you are calling your concept the same way as an
*existing different* concept, and in the following part of your mail you
insist on keeping the confusion.
I don't care about how you call your concept when advertising it to
other persons (except when you voluntary keep the confusion), but for
the sanity of this discussion please be fair and don't use the same word
for two different things.
>> Your concept is hackish because it is based on the conversion of already
>> existing packages into ia32-$(package)_all.deb.
>
> Which is a performance gain. It's faster to reuse available builds.
> It could be used to generate ia32- packages in an i386 build, but that
> complicates the packaging.
How could it be a performance gain if you have to do one more operation?
A gain is when you have to do less operations than previously. Once
again FUD.
>> This:
>> - means we have twice the same package in the archive, which is a very
>> inefficient way of storing data. This will be surely rejected by the
>> ftpmasters.
>
> It isn't the same package. Some packages need to be recompiled (the
> multiarch flavor). That can't be done on the fly, unless both flavors
> are provided. Providing both takes more space, obviously, and adds
> complexity to dpkg and apt.
Even if it is exactly the same package, I am just saying, that applying
you concept results in a bigger archive than the current one.
>> - means the package has to be converted. We need an infrastructure for that.
>
> Already made, unofficial.
I speak about real infrastructure, that is a dedicated server, as well
as a backup server that can do that, as well as the corresponding
automated software which automatically pickup new packages and convert
them. A sort of "conversion buildd".
>> - is a nightmare from the security point of view.
>
> Security support integrated, unofficial.
So you are already able to make a change to a source package, that
propagates automatically and generate new converted packages?
>> - renders the changes in a package a lot more complex. You can't simply
>> run apt-get, patch and dpkg-buildpackage.
>
> Updates are made with debia32 update, unofficial.
Which means you still have to go through a conversion step...
>> - doesn't really scale for multiple architectures. multiarch is not i386
>> on amd64/powerpc. It is everything on everything.
>
> ppc applications run perfectly on amd64, to the extent ppc emulation
> allows. Though running ppc on amd64 isn't interesting, except for
> multiarch development, and it isn't in demand.
> Bottom line, it scales well.
If you want to support 10 architectures with your concept, you need 10
automatic converter. A double of your infrastructure is not what you want.
Also encoding the architecture name (or actually a synonym of the
architecture name) in the name of the package is something error-prone.
>> In short your approach may work correctly for a hundred of packages, but
>> doesn't really scale for the whole Debian archive and all the archive.
>
> The whole archive doesn't need to be converted, that's a common myth.
> Tell me which libraries are missing to run which i386-only applications
> and we'll see. Furthermore, debian's pool is split in many directories
> which allows several machines to be added if recompilation is an issue.
Please stop speaking about YOUR needs, which are not the same than the
ones behind the original multiarch concept. I agree that for running
your i386 pet packages on an amd64 system, you only need a few hundred
libraries. But that's not what we want. We want for example to run ARM
and ARMEL on the same system, in order to provide an upgrade path. We
want to run MIPS N32 packages on a MIPS O32 system. And so on, they are
a dozen of examples.
>> Also I see no point in using multiarch paths (which have been introduced
>> in the toolchain for the original multiarch concept) in your approach.
>
> Multiarch allows everything on everything. It's better than biarch. And
> the best choice to automate my system. Multiarch flavor patches are
> simpler than adding biarch ones.
As already said, you are reusing something that has been introduced, but
for your own different concept. They will be a conflict at some point.
>> On the contrary the original multiarch concept doesn't generate more
>> packages. It basically changes the path were the files are installed,
>> and then (for example) the exact same package is installed on an i386
>> system or on an amd64 system.
>
> Explained above (It isn't the same package... etc).
It isn't the same package, but it is still more packages. Compared to
the original concept that doesn't add more packages.
>> This does not put any load on ftpmaster.d.o and mirrors, does not need
>> an infrastructure to convert packages, introduce no changes from the
>> security point of view and applies to all Debian architectures. The
>> drawback is that dpkg and apt have to be modified.
>
> That puts the load on users. They need to do the conversion I'm doing
> and original packages take more bandwidth. I already explained that in
> #464796. I don't mind explaining stuff again if you tell me what the
> remaining problems are.
Wrong. With the original multiarch concept, you don't have to download
more packages, as there aren't more packages. And there is no conversion
at all. You just allow your system to install packages from different
architecture than the default one.
> Basically, why should I wait for a complex system that will (hopefully)
> be ready for lenny + 1 instead of using a simple one that it's working
> now?
>
Your simple system works for you, but is not something integrable in the
Debian infrastructure (see above). If you want to provide something to
Debian users, it has to be reliable. If not, keep it as a semi-public hack.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: