Re: Architecture all
James Troup <J.J.Troup@comp.brad.ac.uk> wrote:
> I think maybe that architecture _independent_ packages which Depend:
> on an architecture _specific_ package, should be made architecture
> specific, (Iff it *really* does depend on foo. Take boot-floppies for
> example, it is Architecture: all, but Depend:s on mkrboot, an i386
> specific package. That dependency is bogus for non-i386
> architectures, it should only Depend:s on mkrboot for i386), otherwise
> there's no easy way - that I can see - to avoid the situation outlined
> below.
I don't know enough about boot-floppies to comment on that as
a specific case.
However, note that architectural dependence is likely to change
over time.
> Yes this does mean work for the maintainer of bar, _iff_ foo should
> miraculously be ported to another architecture, but I can't see any of
> the 40 or so Architecture-specific packages we have becoming any less
> architecture-specific anytime RSN.
The issue is really: is bar relevant across platforms, not is foo
available across platforms.
> > > However, could it be a problem for users of some other
> > > architecture, who see bar in dselect, try to select it, and get an
> > > unfulfilled dependancy on foo?
> >
> > This should be considered a bug in dselect.
>
> 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. [A warning message when browsing would be graceful.
A warning message with an option to back out when selecting would be
graceful. Unfulfilled dependency is not graceful.]
--
Raul
--
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: