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

RE: multiarch/bi-arch status (ETA) question


> -----Original Message-----
> From: Stephen Frost [mailto:sfrost@snowman.net] 
> Sent: Tuesday, July 05, 2005 4:47 PM
> To: Lennart Sorensen
> Cc: David Wood; Hugo Mills; Goswin von Brederlow; 
> debian-amd64@lists.debian.org
> Subject: Re: multiarch/bi-arch status (ETA) question
> * Lennart Sorensen (lsorense@csclub.uwaterloo.ca) wrote:
> > Of course there is also the issue of how to deal with 
> calling the 32 
> > or 64bit version of program x if you have both versions installed.  
> > Perhaps a helper tool to say run64bit version of x would deal with 
> > that, and your idea of having symlinks in the original 
> location to a 
> > default version would deal well with that.  If not 
> specified you run 
> > the one that has the symlink.
> What's the reason for having both versions of a given app installed?
> I'm pretty sure it was decided that was a bad idea and that 
> there wasn't any good use case for it and so we weren't going 
> to try and support it.
> It just doesn't make sense.

The only reason is to be able to run both of them at your discretion.

> > Of course then there is things like data files in 
> /usr/share which are 
> > not architecture specific.  If you install the same version 
> of both 32 
> > and 64bit for a package, then the files should match and 
> just keeping 
> > one copy should be fine.  If for some reason you install a 
> different 
> > version of one of them (as would happen during upgrades) how do we 
> > resolve those files?  They aren't always seperated into an 
> > architecture all package (which would of course be trivial 
> to handle).  
> > Do we divert the files from the older version somewhere, and then 
> > remove it when the older one is upgraded to match the newer 
> one?  No 
> > point wasting disk space on identical files after all.
> This is only an issue with libraries, and /usr/share should 
> have things which are arch-independent and /usr/lib/<blah> 
> should have arch-dependent things.  If packages don't follow 
> that today then they're broken already and need to be fixed.  
> It is true that there can't be multiple things installed with 
> files in the same place, so any /usr/share usage in libraries 
> needs to be split out in a -common package for that library.  
> This isn't an issue for programs because we're not interested 
> in supporting the unjustified case for having the same 
> program both 32bit and 64bit at the same time.
> 	Thanks,
> 		Stephen

Reply to: