Re: Architecture all

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

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

> > Package foo is i386 only
> > Package bar depends on package foo, but is arch: all
> > 
> > Should package bar be changed over to arch: i386? 
> >
> > Personally, I think not - package foo could always get a arch: all
> > version someday.

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.

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.

Note: I'm not suggesting Packages which are architecture dependent
have to do this.  It won't usually apply to them; if foo really
depends on bar, foo won't be compiled for non-i386 architectures.

> > However, could it be a problem for users of some other
> > architecture, who see bar in dselect, try to select it, and get an
> > unfullfilled 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)?
By unpacking the source for foo and checking the Architecture field in
debian/control?

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