* Lennart Sorensen (lsorense@csclub.uwaterloo.ca) wrote: > On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote: > > 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. > > I want to play with 64bit firefox so i can develop a 64bit plugin for > it. I might at the same time want 32bit firefox so I can use plugins > that are still 32bit only. > > That's just one reason. And a rather unlikely one at that. > Repeat for mplayer where some codecs are 32bit only for now, but others > might run much faster in 64bit and you want to help port it there. So you're going to have your own source code which you're going to be developing with and building. Sorry, I think you'll just have to manage on your own in this case (I mean, really, you're almost certainly going to be doing all of this outside of the existing packaging system *anyway*). I don't think it's sensible or useful to attempt to support having a 32bit and a 64bit version of a given app installed in the packaging system. Your example above doesn't even illustrate a reason to support it. > > 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. > > If we don't then I consider multiarch very broken. That's nice. Stephen
Attachment:
signature.asc
Description: Digital signature