Re: Help identify packages that multiarch support will break
Hi!
On Thu, 2011-03-03 at 14:45:51 +0100, Raphael Hertzog wrote:
> On Thu, 03 Mar 2011, Carsten Hey wrote:
> > * Raphael Hertzog [2011-03-02 15:06 +0100]:
> > > In general parsing the status file should not be done, instead you
> > > should use dpkg-query.
> >
> > Is there any reason for this, except that the format of the status files
> > will evolve?
>
> dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's
> set in maintainer scripts). (this is a new feature in the upcoming version)
>
> And the status file is not a public interface. It's a file used by dpkg.
> If tomorrow dpkg supports an optional SQLite internal database through a
> plugin, dpkg-query will continue to work but your access to the status
> file will not. (This is unlikely to happen any time soon, but you get the
> idea)
Well, the most important reason is that directly parsing the status file
does not take into account the journal files. So yes, nothing should
really be accessing anything under /var/lib/dpkg, although package
manager frontends can be considered currently grandfathered as there's
no sane interface provided by dpkg yet (read libdpkg) for their use,
and they correctly handle the journal files anyway.
> > > You should use "dpkg-query --control-path <package> <something>" to
> >
> > Jftr, there is a lot potential for performance improvements in
> > dpkg-query, some queries can be done way faster even in gawk.
>
> JFTR, there are also 300+ bugs in the BTS and we are two active developers
> on dpkg.
>
> dpkg-query is rarely used in performance sensitive situation, it's not
> really my priority to improve it. But if you want to help, you're welcome.
That's on my TODO list.
regards,
guillem
Reply to: