bootstrap tries to create prefix without taking DESTDIR into account

[gyakovlev]

8e7606f uncovered a regression in bootstrap

The usual distribution/packager workflow is

define prefix as path intended prefix for installation.
during install phase define DESTDIR, so installation is dumped there to be packed up by package manager.

but with 8e7606f installer tries to create a prefix, ignoring destdir.

expected behaviour is to create ${DESTDIR}/${prefix}

so if prefix=/usr it works fine, as /usr always exists. and it will install to ${DESTDIR}/usr/...
if prefix=/usr/lib/rust/$ver , bootstrap will attempt to create prefix directory directly if it does not exist yet, but it should prepend DISTDIR at this step, as creating directories on host filesystem is not allowed in sandboxed builds, and it will fail if building as non-root user.

[Mark-Simulacrum]

I am not sure I follow entirely, but usually we accept PRs for such changes, especially if you can point at other build systems which do the same.

[gyakovlev]

I know this is a trivial change, but my rust is worse than weak. I'll try but it will take me a bit of fiddling.

all the build system I know do that (autotools, cmake, meson and many more)

the problem here is that it tries to create directory before canonicalizing it, on real system path.
and let prefix = add_destdir(&prefix, &destdir); defined later in the code.

imagine this scenario (makefile example for simplicity):

./configure --prefix=/opt/rust
make
make install DESTDIR=/tmp/myrust

Normally it will prepend /tmp/myrust to prefix value, so it will be installed to /tmp/myrust/opt/rust.
and package manager takes that directory and archives it.
this will work as unprivileged user, so one does not need permission to create /opt/rust

but with current logic, boostrap will attempt to create /opt/rust directly, and not /tmp/myrust/opt/rust as it should. and will fail at this step if current user has no permissions. and building as root is always bad idea.
installation itself is fine, and it installs to DESTDIR prefix, but it can't reach installation if it failed earlier.

[jyn514]

@gyakovlev would this be fixed by #80240 ?

[gyakovlev]

@jyn514 yes, I believe it's the same problem fixed in #80240 and reported in #80238
I'll close it for now then. thanks for the ping! Just got back from holiday break.