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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]