Re: Multiarch interfaces
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/
Reply to: