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

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


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: