Control: tag -1 - moreinfo + confirmed

Hi Guillem,

Guillem Jover wrote:
> > Guillem Jover wrote:
> > > This package contains the «debsums» program, which directly accesses
> > > the dpkg internal database, instead of using one of the public
> > > interfaces provided by dpkg.
> > 
> > JFTR: This is not true. I didn't find a single place in the debsums
> > script where $admindir is accessed directly. Instead it is always
> > passed to a dpkg, dpkg-query or dpkg-divert call as you asked for.
> Well I see in debsums the md5sums_path() function which does access
> it.

Granted. I just looked for $admindir, but not $DPKG. My fault. Thanks
for pointing out this detail.

> Ideally debsums would only pass the admindir if it has been specified.
> And then it would also only use --root on dpkg commands if that's what
> has been passed to it, which would imply no need for a hard-coded
> dpkg database pathname.

Being able to only use --root would be very preferable indeed.

> Of course one problem is that dpkg-query does not have a --root
> option! But I think I have a branch somewhere implementing that, so
> I'll add this to 1.20.1. :)

Much appreciated!

I though see one problem with this: IIRC, the piuparts guys sometimes
use debsums as backport on stable.

Cc'ing them if this is still the case and if they see any issues if a
debsums upload in the not-so-far future would depend on a very recent
dpkg version. (IIRC last time they needed a debsums backport, this was
because we fixed bugs they wanted to be fixed in their setups as soon
as they were found and fixed.)

> > Leaves the build-time configuration of the admindir: How can I query
> > dpkg for the build-time location of its admindir?
> > 
> > And how can I determine the admindir of a chroot with a call to an
> > external dpkg binary outside the chroot, which, as I understand you,
> > can have a different admindir.
> So with the above, the idea would be that you do not need to.

Yep. --root for the win! :-D

That's definitely the way to go.

> > I just tried "dpkg-query --control-show sendfile md5sums" in a minimal
> > pbuilder chroot where I just installed sendfile to see how that error
> > looks like.
> > 
> > To my surprise, despite sendfile_2.1b.20080616-6_amd64.deb does not
> > contain a files with md5sums, "dpkg-query --control-show sendfile
> > md5sums" works and /var/lib/dpkg/info/sendfile.md5sums exists.
> > 
> > So it seems as if dpkg now automatically generates md5sums files if
> > not present. Just checked dpkg's changelog and this feature seems to
> > exist since 2012.
> > 
> > Which means that debsums_init is actually obsolete since 2012.
> > 
> > So I will happily remove debsums_init with the next upload.:-)
> Yes, thanks. :)
> > > If the file is missing an error will be returned.
> > 
> > So how can this file be missing if dpkg generates them?
> That would be the case if a package had been installed with an ancient
> dpkg version and then never upgraded.

sendfile actually was a good candidate (the last maintainer upload
before 2020 was in 2011), but it got adopted recently and also had
some NMUs between 2012 and 2014. Of course this wouldn't have made a
difference in a just unpacked pbuilder chroot. :-)

> But as mentioned above «dpkg -C» will complain, so I'd leave it to
> the user to handle TBH. Also because generating the md5sums from the
> installed files is a bit misleading as if they have changed then
> they will be "bogus", I mean I guess this is better than nothing,
> but not ideal.

Full ack. debsums_init did the very same for the very same reason,
just about 5 years before dpkg did. (According to the changelog it got
introduced in 2007.) This also explains very nicely why the according
lintian warning is still important.

                Regards, Axel
 ,''`.  |  Axel Beckert <>,
: :' :  |  Debian Developer, Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Reply via email to