On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: > >> Wouter Verhelst <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
