Re: multiarch status update
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...
> 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.
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.
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".
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Reply to: