On Sat, Feb 19, 2011 at 08:48:45PM +0100, Goswin von Brederlow wrote: > > On Wed, Feb 16, 2011 at 05:12:03PM +0100, Goswin von Brederlow wrote: > >> It actually makes less sense. > >> You have identified the 2 cases of arch:all apckages: > >> 1) truely architecture independent and satisfies dependencies for any > >> arch > >> 2) meta packages that are placeholder for an arch:any package > >> So why then forbid the use of the Multi-Arch field to let maintainers > >> choose between the 2 types? > > What? We didn't do that at all. This thread is about making it clear that > > the Multi-Arch field *can* be set on Architecture: all packages! Case 1 is > > Multi-Arch: foreign; case 2 is Multi-Arch: none. > Yet Multi-Arch: same is forbidden in the specs. Which you would need for > a meta package that depends on a library. Please cite an example where this is not an absolutely preposterous thing to do. Library dependencies are satisfied via the dpkg-shlibdeps mechanism, which generates direct dependencies from the package containing the binary to the package containing the library it uses. I've never heard of anyone depending on an architecture: all package as a proxy for *libraries*, and can't think of any reason that would be sane to do. > By smashing arch:all packages to :native you greatly reduce the > installability of packages. Lets take a simple game (freeciv) as example > and pretend this were a non-free package available for i386 only: > Package: freeciv-client-gtk > Architecture: i386 > Depends: libatk1.0-0 (>= 1.29.3), ..., freeciv-data (>= 2.2.0), ggzcore-bin > Package: freeciv-data > Architecture: all > Version: 2.2.4-1 > That means freeciv will be uninstallable on amd64 for no good reason. Yep - but under the current proposal we could easily fix that by annotating freeciv-data as Multi-Arch: foreign. The idea of being able to install foreign-arch packages *at all* is entirely new in Debian. I don't think requiring the arch: all package to be marked Multi-Arch: foreign is all that much of a burden. > Could we default arch:all leaf packages (no further Depends) to > Multi-Arch: foreign? That would cover data packages like the above > example. That should be local enough to check. Since that doesn't require dpkg to look beyond one level of dependencies when calculating, I would be ok with that as a middle ground, if the dpkg and apt maintainers agree. Though I suspect the cases where this matters will be few in practice. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature