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

Re: Dpkg .list files far from complete?


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
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.


Reply to: