Your message dated Thu, 17 Jun 2021 03:41:29 +0200
with message-id <[email protected]>
and subject line Re: Bug#913781: reprozip: Script accesses internal dpkg
database
has caused the Debian Bug report #913781,
regarding reprozip: Script accesses internal dpkg database
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
913781: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913781
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: reprozip
Source-Version: 1.0.10-1
Severity: important
User: [email protected]
Usertags: dpkg-db-access-blocker
Hi!
This package contains a scripts, which directly access the dpkg internal
database, instead of using one of the public interfaces provided by dpkg.
The code in «reprozip/tracer/linux_pkgs.py» should be switched to use
«dpkg-query --listfiles PKGNAME...». To avoid a performance loss, the
code can batch multiple packages on a single call (according to the
command-line length limit), which will get output as different stanzas
separated by a blank line (even if the package does not exist).
This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.
Thanks,
Guillem
--- End Message ---
--- Begin Message ---
Version: 1.0.16-1
Hi!
On Wed, 2020-09-23 at 17:45:45 -0400, Rémi Rampin wrote:
> 2018-11-15 23:33:30 UTC-0500, Remi Rampin <[email protected]>:
> > I have gone ahead and implemented what you describe, it should be in
> > the next minor release of ReproZip. It also turns out to be faster.
>
> This is present in reprozip/1.0.16-1 that was just uploaded so I
> believe it can be closed too (see
> https://github.com/VIDA-NYU/reprozip/pull/330).
Indeed, this seems fixed in the latest version present in Debian. Even
though the closure was missed in that upload, I'll close this with the
appropriate version now.
Thanks,
Guillem
--- End Message ---
