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
