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

Re: Architecture all

Raul Miller <rdm@test.legislate.com> writes:
> > > If bar depends on foo and foo is not available for platform X, bar
> > > is not relevant to platform X.  (How is bar relevant to platform X
> > > if it can't be installed?)
> > 
> > If bar is architectural neutral data stored in an architectural
> > format.  [I believe this thread is rooted in a discussion of
> > quake-lib.]
James Troup <J.J.Troup@comp.brad.ac.uk> wrote:
> How is bar relevant to a user of platform X, if bar can't be installed
> by dselect or dpkg -i?

Um.. why can't bar be installed by dpkg -i (or even by dselect,
using appropriate overrides key sequences)?

As for quake-lib, it contains a variety of pictures and sounds.
The archive format is a little odd, but I believe it's documented,
and I believe there's other programs that can work with it
(besides quake).  Not, in particular, that this is very different
from architecturally specific boot mechanisms.

> Type B: (will probably never be fulfilled) 
> [ This hypothetical example assumes an m68k user ]
> foo 2.3-5 (Arch: all) depends on svgalib. svgalib will probably never
> be compiled for m68k, so this package can never be installed, but yet
> it's being offered to the user in dselect.

never say never.  In particular, the ggi project would indeed allow
svgalib to be compiled for m68k (admittedly, I don't think it will
be releasable by the end of this year).
> I'm interested in sorting things out for Type B, not in how dselect
> deals with Type A.



TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: