[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiarch status update



Le Lun 15 Mai 2006 17:02, Olaf van der Spek a écrit :
> On 5/15/06, Romain Beauxis <toots@rastageeks.org> 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
> > listmaster@lists.debian.org
>
> 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                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpI9AcjLsBC5.pgp
Description: PGP signature


Reply to: