Re: multiarch status update
Wouter Verhelst <wouter@grep.be> writes:
> On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <wouter@debian.org> writes:
>>
>> > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
>> >> Wouter Verhelst <wouter@debian.org> writes:
>> >> > Have you considered employing the alternatives system (or something
>> >> > similar)? What I'm suggesting is that you'd basically get a /bin64 and a
>> >> > /bin32, where binaries install themselves in /bin by default but divert
>> >> > to the /binXX when both versions are installed, and use symlinks in an
>> >> > update-alternatives way to select the default.
>> >>
>> >> Each package that deems it neccessary can choose to do so.
>> >
>> > That's not what I meant, really.
>> >
>> >> I imagine the count to be near 0. Certainly nothing dpkg should handle
>> >> automagicaly for all debs.
>> >
>> > Why not?
>>
>> Extra complexity with extra risk of breaking for no practical gain.
>
> That could technically be said about all of multiarch...
I see a big gain in having a 32bit OOo for amd64 or being able to run
any of the old 32bit software.
I see no gain in having both a 32bit and 64bit make for example.
>> Also don't forget that you can have more than 2 archs but dpkg can't
>> have more than 2 diversions.
>
> Err, okay. I guess I shouldn't have mentioned "alternatives", because
> that clearly confused you.
The alternative is not the problem. The diversion is.
> What I meant to say is that you could have dpkg set up things so that if
> multiarch is in effect, files would be installed in /multiarch/i386/bin
> rather than in /bin (or some such), and that symlinks would be made to
> /bin so that the entire process would be transparent to a package.
> Alternatively, you could also set it up so that files would be installed
> in /bin by default, but then moved to /multiarch if the same package,
> but compiled for a different architecture, would be installed.
>
> Next, you would create some program to manage those symlinks. If you
> prefer to run firefox in 32bit mode by default, you could say
> "update-multiarch --config firefox i386", and it would move symlinks
> around so that /usr/bin/firefox, and all files from that package with
> it, refer to the i386 version of firefox rather than the amd64 version,
> or the ia64 one, or what have you.
Note that this would require some packages to use the arch specific
binaries. E.g. mkinitramfs or debian-installer need the right arch for
their binaries. With the arch/bin dirs being optional those packages
then have to support both ways. Another complication.
With only one arch per binary only the Depends/Build-Depends have to
be arch specific and not the scripts itself.
> I mentioned the alternatives system because it already exists and it
> does something similar to what I'm proposing; not because I'm proposing
> you use exactly that to fix these issues.
>
> The whole point really is "why not use symlinks?" and "We've already
> fixed a similar problem with symlinks", not "use the alternatives
> system".
The alternatives system is the exact and perfect solution to this
problem and is already existing and working. Not using it just means
you are duplicating its functionality.
The only difference is that packages use alternatives manualy while
you want dpkg to automagicaly add alternatives. The problem lies in
this magic instead of the handfull of packages that would even need
32/64 bit implementing it themself. The only currently known case
where users might want 32bit and 64bit of the same binary are
browsers. And even for that there is no good reason why just 32bit
isn't enough. 64bit is just wanted for the slight speed increase.
MfG
Goswin
Reply to: