Re: Architecture all

[James Troup <J.J.Troup@comp.brad.ac.uk>]

Raul Miller <rdm@test.legislate.com> writes:

> However, note that architectural dependence is likely to change over
> time.

Not really, IMO; of the ~40 architecture specific packages I know of,
~3 are likely to change, and possibly (but not very likely) some of
the binary only ones might be recompiled for other architectures.
 
> The issue is really: is bar relevant across platforms, not is foo
> available across platforms.

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?)

> > And how is dselect meant to tell the difference between foo not
> > being available because it's obsolete, hasn't made it out of
> > Incoming/ or just hasn't been compiled for that architecture yet,
> > etc. and foo that will never be available for that architecture
> > (e.g. svgalib for m68k)?  debian/control?
> 
> Why should it matter? Dselect should have a graceful way of dealing
> with the condition.

With what condition?  Is this just a rant against dselect?  The point
is that dselect can't, if you allow architecture independent packages
to depend on architecture specific ones, distinguish packages which
could never (&|in the foreseeable future) be installed on platform X
and packages which can't currently (i.e. temporarily) be installed on
platform X.  I don't care about how dselect deals with unfilled
dependencies other than that, it isn't what I was talking about.

-- 
James


--
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 .