Bug#469035: libc6-i386: include mutiarch ld.conf from i386
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?
> 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.
> 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.
> - means the package has to be converted. We need an infrastructure for that.
Already made, unofficial.
> - is a nightmare from the security point of view.
Security support integrated, unofficial.
> - 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.
> - 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.
> 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.
> 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.
> 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).
> 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.
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?
Reply to: