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

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: