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

Re: Help identify packages that multiarch support will break



On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
> 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)

Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat) or (2) list all package names
(using --status)?

I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
glad to migrate them to dpkg-query, but both solutions above have
drawbacks. (1) is not future proof and will miss the addition of new
fields unless the utility is updated; (2) has a race condition in asking
the currently installed packages and providing them to --status (beside
being a horrible hack in requiring to list all package names as
arguments).  Am I missing something?

Having the ability to pass a package (wildcard) pattern to --show would
be enough to solve this problem.

Do you want a bug report about this?

Thanks to the mighty dpkg maintainers!
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams

Attachment: signature.asc
Description: Digital signature


Reply to: