Hi, I've modified some of the dpkg multiarch interfaces in my WIP branch on hadrons.org, given their current inadequacy. Here's two of them, I'll be starting a different thread for other ones.
I've added support for virtual fields to dpkg-query, those are output only fields that can map to specially formatted text or sub-values of normal fields. They are currently prefixed with «virt:» as in «virt:Virtual-Field-Name». The reason for this is that otherwise possibly legitimate fields would get shadowed and could never be exposed even if they had been parsed correctly (through the arbitrary arbs fields), losing meta-data, this affects the PackageSpec virtual field; and while the field has changed name I'll probably rename to something resembling the more usual field name form, like virt:Package-Spec for example. (As a side effect of this I'll be merging support I had laying around for virt:Summary and virt:Status-Abbrev, I could also name the first virt:Short-Description but's more verbose although probably more commonly understood in deb circles, or we could even have both.) 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). regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
