The post install is failing when dpkg is configured with a root and run
as an unprivileged user. This is an issue partly with packaging and
partly with the upstream package (I think). The upstream issue can be remedied with a patch in
the packaging.

My suggestion for a fix is to modify update-info-dir such that it takes
an argument (eg. --root <path>) prepend that argument to all file paths
used.  Then in the post install call update-info-dir with $PKG_ROOT as
the argument, eg. update-info-dir --root $PKG_ROOT. Any fix will do
though.

Glenn

Am 15.10.2021 um 07:42 teilte Glenn Washburn mit:

Hi Glenn,
Did you test of texinfo 6.8 eventually solves the issue?

Further I don't understand the use case: under which situations will a
configuration script will be run as non-privileged user?

Hilmar

Quoting Hilmar Preuße (2022-01-14 23:57:32)

None. Glenn also filed #996435, #996438 and #996542 and my answer to the latter
also holds for this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996542#25

Thanks!

cheers, josch

Am 15.01.2022 um 07:54 teilte Johannes Schauer Marin Rodrigues mit:

Hi Josch,

Hilmar

Josch, no need to answer disingenuously for me. There is in fact a use
case and it is in the metioned bug. Thank you for providing that
context.

Hi Helmar, I haven't tried with texinfo 6.8. Looking at the
update-fmtutil script in tex-common, which is doing most of the work in
the texinfo postinst script, it looks like the issue still exists.
There are many hardcoded absolute paths in that script.

I believe my original suggestion still holds if update-info-dir is
replaced by update-fmtutil.

I'll restate my use case briefly here. The use case is installing
packages as an unprivileged user to a user writable location (I don't
have privileges on this machine and can't chroot). This can be done by
invoking the dpkg binary with the "--force-script-chrootless" option
and works, but the post install fails.

Glenn

Quoting Glenn Washburn (2022-01-17 08:42:24)

And just as I told you in that other bug, you can achieve that same thing
without being root by using either fakechroot or by unsharing the user
namespace. But you definitely have privileges for the former.

We don't need to put support allowing maintainer scripts to be run as another
user as the root user if there are mechanisms that can fake the root user. For
good reasons package maintainers are cautious when it's about increasing the
complexity of their maintainer scripts and it should only be done when it's
absolutely necessary.

The final decision of course lies with the texinfo maintainers and not me. I'm
just explaining for you (again) why this is not needed. Just have a look at the
mmdebstrap code and how it fakes being root to create chroot tarballs without
any root privileges. Take that code and use it for your own project and you
will not have to file another of these bugs as all packages will just magically
work without any changes. If you need help understanding how mmdebstrap does
what it does I (again) offer you my help.

Thanks!

cheers, josch

Am 17.01.2022 um 09:10 teilte Johannes Schauer Marin Rodrigues mit:

Hi,

I didn't decide how to go further yet. For now I reopen and set severity
to wishlist as it doesn't sound like a bug to me.

@Glenn: if you have patches to implement your request we'll think about
adopting them. Let us know.

Hilmar

Chroot is a semantic I'e been trying to avoid because I'm wanting to
use the main filesystem as much as possible (ie only install what's
not already installed on the main system). I believe unprivileged
overlayfs is what I want. I could use overlayfs in UML, but so far
trying to avoid that as a dependency. I believe Ubuntu has a patch for
this, but I don't think its been accepted to mainline yet. So here I am.

Yes, I've heard this before. Probably at a minimum this should be
documented in the dpkg debian man page, perhaps under script-chrootless
or DPKG_ROOT, noting that that not all distro packages honor this
method of package install.

Thank you Josch. I don't believe this can help me because of the afore
mentioned issue with chroot. Am I mistaken? You can take this
discussion off the bug list if you like. It seems to be venturing into
irrelevant territory.

Glenn