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

Re: kernel-package rules file patch for UltraSparc



Ben Collins <bcollins@debian.org> writes:

> On Sat, Apr 03, 1999 at 01:09:30PM -0400, Steve Dunham wrote:
> >   IMHO, we sould follow their lead, and go with a hybrid 32-/64-bit
> >   system.  This way:
> >
> >      * Programs that need 64 bits can be compiled as such.
> >      * Programs that don't need it don't incur the performance
> >        penalty of extra code/data size.
> >      * We don't have to recompile everything.  (If we completely split
> >        into sparc and sparc64 dists, it will be even harder to keep
> >        the packages in sync with the other archs.)
> 
> 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?)

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.

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.

--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>


Reply to: