Bug#944968: popularity-contest: Program accesses internal dpkg database
On Sat, Feb 01, 2020 at 07:09:56PM +0100, Bill Allombert wrote:
> On Sat, Feb 01, 2020 at 07:02:38PM +0100, Guillem Jover wrote:
> > On Thu, 2019-11-28 at 22:41:44 +0100, Bill Allombert wrote:
> > > On Thu, Nov 28, 2019 at 08:55:00PM +0000, Niels Thykier wrote:
> > > > While it would take a bit of restructuring / refactoring, I think it
> > > > would be possible to use a single dpkg-query for everything and still be
> > > > able to process the data in a "streaming" fashion.
> > >
> > > Yes this could work, however this is assuming that dpkg-query is not
> > > allocating everything in memory at once.
> >
> > dpkg-query will load everything in memory, in the same way it does
> > while doing a «dpkg --install» or similar. The key here is that these
> > files are just going to disappear in an inminent future, and anything
> > relying on them will just break. Also dpkg will be moving into keeping
> > the entire package filesystem knowledge in a single database file anyway.
>
> A database file normally allows to extract fields without having the whole
> database in memory. dpkg should provide an interface to that.
In fact, popcon do not even require that. If it is a single line-based text file,
popcon should be able to read it line-by-line, freeing previously read lines
as soon as it does not need them. The total memory used will be of the
order of the generated popcon report.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: