Le Lun 15 Mai 2006 17:02, Olaf van der Spek a écrit : > On 5/15/06, Romain Beauxis <[EMAIL PROTECTED]> wrote: > > I have a multiarch on my amd64 system only because I want to use > > applications that I can't use or does not have the same > > functionalities with amd64 (mostly firefox, ooo and mplayer > > then...). > > But I'll be happy to have a full amd64 system if only they could > > provide the same with it. > > > > So, as for Pierre, a binary package per multiarch system seems > > obviously the solution, since a user needs only a given > > functionalities. > > > > Why would you see many binaries installed from the user point of > > view? with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > For example because one user would like to have the absolute latest > version of a certain package while other users are satisfied with the > version in stable or testing. > > Or because you've got scripts that depend on php4 while you've also > got scripts that depend on php5. > > Or because you'd like to compile a binary with libmysqlclient14-dev > and then compile a binary with libmysqlclient15-dev.
yes, but for the cases you mention, there is real reasons to stick with one or the other *versions* of the software. Here we talk about the *same* version of the package, but with different archs. While it makes sense for libraries, because you may want the $arch1 version of foo that needs libquux in $arch1 *and* bar in $arch2 that needs libquux also but for $arch2, you obviously need multiarch for libraries. but I just cannot find any compelling reason to have multiarch for binaries. Sometimes you want i386 browsers to make use of flash/java/... plugins, or you want amd64 ocaml so that string are not limited to a length a bit smaller than 16Mb, ... but I see no real case of applications that you need in both arches at the same time. And even if that was the case, I pretend that it is a case by case problem, and that it does not makes sense to force every single binary package to be multiarch-friendly. For libs that will already be hard enough. And for the few (and I still need a *good* example of such a software) that needs it, a configuration through alternatives seems to solve the problem, and that is a technology we already understand and work with every day. Another point is that for libraries, you need that or that version of the library, and the linker will always choose the adequate one. For a binary, if I want 'foo', I have to chose once for all (through $PATH) if I prefer 64bits over 32bits *OR* the reverse. Which makes no sense at all to me. Sometimes you prefer the 64 bits version, sometimes the other. alternatives are good at it. any other system seems broken to me. honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both instances installed. I've though hard enough, and I've found none. -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgpWPB1c8ZMMc.pgp
Description: PGP signature
