Re: kernel-package rules file patch for UltraSparc
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 <b.m.collins@larc.nasa.gov> Debian GNU/Linux
OpenLDAP Core - bcollins@openldap.org bcollins@debian.org
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
Reply to: