Hi Guillem, On Fri, Nov 18, 2011 at 10:45:06AM +0100, Guillem Jover wrote: > The other interface change is related to the --foreign-architecture > option, the problem with it comes from the fact that the architectures > supported by the database are not configuration, they are state. This > shows up in several ways. When a front-end needs to load the list of > architectures, it needs to get someone to parse dpkg.cfg files, this > is currently done by dpkg itself, and the list can be retrieved with > --print-foreign-architectures, the problem comes when wanting a > front-end to load them through libdpkg. Making the latter have to > execute «dpkg --print-foreign-architectures» would be suboptimal, and > making libdpkg have to load dpkg.cfg would be distasteful. Another > issue is that if the list of foreign architectures is on the > configuration files it makes it slightly more tricky to cross-grade > dpkg, and it makes it fairly easy to accidentally remove architectures > required by the database. I've fixed all this by replacing the > --foreign-architecture option with two new commands --add-architecture > and --del-architecture which will perform sanity checks and store and > load the architecture list (including the native arch) in an internal > db file under /var/lib/dpkg. (I'll probably rename --del-architecture > to something like --remove-architecture before pushing, to match the > convention in the rest of the dpkg CLI). Thanks, this makes sense to me. On Fri, Nov 18, 2011 at 12:01:57PM +0100, Raphael Hertzog wrote: > > I've fixed all this by replacing the --foreign-architecture option with > > two new commands --add-architecture and --del-architecture which will > > perform sanity checks and store and load the architecture list > > (including the native arch) in an internal db file under /var/lib/dpkg. > This look ok to me too. --print-foreign-architectures must stay of course, > APT already relies on this interface. > Ubuntu will have to come up with a small transition strategy since they > modified dpkg to provide a supplementary configuration file precisely > to auto-enable i386 on amd64. Yep, that doesn't sound like a problem. On Fri, Nov 18, 2011 at 07:00:09PM +0100, Guillem Jover wrote: > > Maybe we could have a "multiarch-config" binary package provided by > > dpkg that only provides a debconf interface to enable/disable > > supplementary architectures. And the default answer could be changed > > for each vendor/architecture combination. > The thing possibly needed is a mapping from native arch to supplementary > arches, supported by specific CPUs (not just amd64-i386), say: > amd64 → i386 > ia64 → hppa, i386 > s380x → s380 > mips ←→ mipsel > armhf → armel, arm > armel → arm > powerpcspe → powerpc > ppc64 → powerpc > etc. > Except for things like possibly firmware, which AFAIR there seemed to > be consensus should be kept as arch:all for now (otherwise they'd > require Packages file for lots of architectures), the rest require > run-time support from libc. The problem with adding the arch from > the libc package is that's a chicken and egg situation. What libc support do you mean? All per-architecture executables should have dependencies on the libc package for their arch anyway, so I don't see how libc support really enters into this. -- 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