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

Re: popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packageso


Bill Allombert wrote:

> This is not possible: forking dpkg for all installed packages would be way to slow and 
> resource intensive. We need a better option.

It seems that what popularity-contest currently does is something like

 for each installed package:
	for each file in its files list which is under /bin, /sbin,
			/usr/bin, /usr/sbin, a subdirectory of /lib,
			or /usr/games, or is a .a, .h, .pm, .php,
			/boot/System.map- file, or is currently
			in use by a process:
		stat it;
		check its atime and ctime and store corresponding results.

In an ideal world on seeky disk drives, it would be better to read
.list files in the order stored on the file system.  Being lazy, I'll
just ask: does dpkg have an interface that could learn to do that in
the future?  That is, I'm imagining a command that will give a dump
like this:

	Package: foo

	Package: bar

Bonus points if this interface has an option to point to the file on
disk rather than asking the caller to take care of tracking down

Of course alternative methods might be possible; I ask the above
because I am worried about the memory usage from
"dpkg-query -L $(list-all-packages)".

Reply to: