Hi, On Fri, 18 Nov 2011, Guillem Jover wrote: > 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.)
I already noticed this, I agree it's cleaner and this change will not break anything AFAIK (only debsums tried to use that field, but has fallback code if the field doesn't exist, I filed a bug so that they remember to update the code once we have the final implementation in place). > 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 I don't follow you here. What's the problematic scenario? > 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. 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
