On Sat, Apr 03, 1999 at 09:35:34PM -0500, Adam Di Carlo wrote: > > Right, sparc64 should just be an overlay on top of sparc32. Problems > > that will arrise have to do with dpkg/apt/dselect being able to > > distinguish prefered builds (ie. prefer an arch=sparc64 over an arch=sparc > > of the same package if available) or name the packages with a 64 > > extension somewhere (which would be horribly difficult to maintain just > > for one port). > > Yurk. Is anyone talking to Ian about this stuff? > > There are three possible workaround I can think of. Neither is going > to work too well, however. I hope we only have a pretty small number > of the 64-bit required packages. > > One alternative is simply to have a new distribution area, > binary-sparc64. I don't know how the archive maintainers would feel, > but we could have that distribution be *only* an overlay distribution. > That is, it would assume that you have sparc available as well. With > things like apt around, this is certainly doable. However, it might > be real confusing for users and wierd. (Could we have a mostly > symlink farm sparc64?)
I think this is the prefered way, atleast the way I see it. The worst problem is that it isn't just a recompile of the package, any libraries need to go into /usr/lib64 and headers into /usr/sparc64-linux/include. Not full of symlinks though (except for the boot disks?). > Another possibility will be to ship 'fat packages' with both versions, > and use alternatives to manage them, i.e., in postinst, based on the > output of uname -m. This might be tough for maintainers, however. Hard to maintain, seems like more work and overbloat that most people don't want to download just for sparc32. > Lastly, we could hack out a way to have a subarch pseudo package, > i.e., sparc-64, and we could manage subarchitecture dependancies that > way (i.e., depends, conflicts). I guess it would have to be priority > required so that apt doesn't try to remove it. Maybe a sub-arch type thing would be good, but I think we'd have to hold our breaths since the amount of work across the package management programs would be immense. -- ----- -- - -------- --------- ---- ------- ----- - - --- -------- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED] UnixGroup Admin - Jordan Systems The Choice of the GNU Generation ------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
