Re: multiarch: dependency-oriented vs package-oriented
- To: firstname.lastname@example.org
- Subject: Re: multiarch: dependency-oriented vs package-oriented
- From: Goswin von Brederlow <email@example.com>
- Date: Mon, 03 Aug 2009 10:43:58 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20090731192254.GC17205@dario.dodds.net> (Steve Langasek's message of "Fri, 31 Jul 2009 21:22:54 +0200")
- References: <email@example.com> <4A709642.firstname.lastname@example.org> <20090729185816.GB20301@dario.dodds.net> <email@example.com> <20090731192254.GC17205@dario.dodds.net>
Steve Langasek <firstname.lastname@example.org> writes:
> On Wed, Jul 29, 2009 at 11:30:33PM +0200, Goswin von Brederlow wrote:
>> >> Moreover, this is not the only exception. Thousands of desktop and server
>> >> packages that contains executable binaries (applications) compiled from
>> >> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>> >> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.
>> > First, why do these packages need to be cross-installed? If they don't need
>> > to be, then there's no reason to set the Multi-Arch field on them at all.
>> I want zsh for be "Multi-Arch: foreign" so zomg:i386 and
>> flowscan:amd64 can be installed. But then zsh:amd64 and zsh-dbg:i386
>> would be installable, which clearly does not give functional debugging
> All well and good that you want this, but both zomg and flowscan are
> arch:any packages present on both architectures. I don't see any compelling
> reason to support this case on the first pass (i.e., make this supportable
> in squeeze without incompatible changes to Depends:), this looks like a
> wishlist request and not something critical - as is, say, getting rid of
This was just an example. I can probably do the same with bash and
google-earth. Do you want to force everything that depends on bash to
be 32bit now?
Anything named *-dbg must be handled special in apt/dpkg till they all
go away and become .ddebs. And they must be handled special too.
If that is not done then no package with *-dbg flavour or .ddeb can be
"Multi-Arch: foreign", which put a serious dampner on multiarch