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.]
How is bar relevant to a user of platform X, if bar can't be installed
by dselect or dpkg -i?
(Or is it acceptable to require packages to be installed with
--force-depends these days?)
> > > 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.
>
> Er.. if we're not talking about how dselect behaves when the user
> selects a package whose dependencies cannot currently be filled,
> then what are we talking about?
Packages whose dependencies will never or not in the forseeable future
have their dependencies fulfilled.
Type A: (cannot currently be fulfilled)
jpeginfo 1.4-2 depends on libjpegg6a. libjpegg6a is a new package and
is still stuck in Incoming/. This is a transient thing.
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.
I'm interested in sorting things out for Type B, not in how dselect
deals with Type A.
> You seem to be claiming that dselect can't have an acceptable
> behavior based on currently available information, and you've
> proposed a change in that information to work around this.
Yes.
--
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 .
Reply to: