Re: Dpkg .list files far from complete?
Hi!
On Wed, 2015-10-21 at 11:56:00 -0600, Philip Prindeville wrote:
> > But you are partly reinventing "dpkg -V"...
> > On Tue, 29 Sep 2015, Philip Prindeville wrote:
> >> On 05/01/2015 06:51 AM, Raphael Hertzog wrote:
> >>> On Thu, 30 Apr 2015, Philip Prindeville wrote:
> >>>> But then I need to read either /var/lib/dpkg/info/<package>.list for a
> >>>> list of installed files, or else
> >>>> /var/lib/dpkg/info/<package>:<arch>.list ... and I can't figure out what
> >>>> the rule is for knowing when it's the latter.
> >>> When the package is "Multi-Arch: same" but you should not really access
> >>> those files directly,
These are in principle internal details, and the format of the db is
specified in the format file.
> >>> instead you should rely on dpkg-query -L to access
> >>> those list of files.
Yes, please.
> >>>> Oh, almost forgot. Is there a tutorial to using the Dpkg::* classes?
> >>> Not that I know. There are the manual pages, that's all.
If something is not properly documented, or not clear, please file a
bug report, so that it can be improved.
> >> Might add a few extra classes for some convenience functions, like reading
> >> the .list and .md5sums files... since I'm trying to avoid spawning hundreds
> >> of sub-processes by the tool, which would be orders of magnitude slower than
> >> reading them in-process.
«dpkg -L» can be used with multiple packages on the command-line, so
the queries can be batched. There's currently no interface to retrieve
md5sums files contents in bulk. There's only something like «dpkg-query
--control-show dpkg md5sums».
If «dpkg -V» is not good enough, I'd rather improve that. If you still
need to access those files from perl, I'd rather add the modules to
the libdpkg-perl packages, so that at least the internals are confined
in dpkg itself.
> >> Also had a question about how certain files, like those created in .postinst
> >> or .conffiles scripts, aren't included in the pkg.list file? For instance,
> >> any of the python library packages generate .pyc files from the .py files,
> >> but the former aren't included in the bill-of-materials (i.e. the .list
> >> file).
> >>
> >> I'm writing a script that runs on a system and finds all
> >> deleted/added/modified files on that system per the Dpkg information.
> >>
> >> For instance, if you had:
> >>
> >> /etc/libvirt/qemu/networks/backbone.xml
> >>
> >> that would show up as an "added" file, related to the libvirt-daemon-system
> >> package.
> >>
> >> If you modified (i.e. md5sum mismatch with the .md5sums file) the file:
> >>
> >> /usr/share/misc/pci.ids
> >>
> >> that would show up as a "modified" file, belonging to the pciutils
> >> bill-of-materials.
> >>
> >> But I'm seeing about 13,000 files on my system that look like they are
> >> related to packages, but don't appear in the .list files for the installed
> >> packages (like all the .pyc files).
> >>
> >> Is there a way to relate those files to their packages that I'm not figuring
> >> out?
Currently not in native way, no. See
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_dpkg_handle_volatile_files.3F>,
but see below…
> >> I know that in the RPM 4.0 packaging, ALL files related to a package
> >> (including socket files in /var/run, or synthesized config files like
> >> sendmail.cf), must be explicitly called out.
> >>
> >> What am I missing here?
you might not be aware of the cruft package, which seems to be doing
in a way what you describe above. And it has a list of such files, but
I'm not sure how comprehensive it is.
Thanks,
Guillem
Reply to: