[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Multiarch interfaces



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


Reply to: