conf / scripts: Fix unprivileged "make install" #71

Merged
Jan Lindemann merged 3 commits from jan/feature/20260818-conf-scripts-fix-unprivileged-make-install into master 2026-08-18 17:38:18 +02:00 AGit

This PR fixes errors during "make install" as unprivileged user. It does little more than installing files into a fake root environment which in itself is not useful for anything meaningful. But users seeing errors during "make install" will understandably assume that something is very off, so this PR just fixes the errors.

defs.mk: Don't use plain /usr/bin/install

In a development tree, $(INSTALL) falls back to plain install(1), which refuses dead symlinks, so unprivileged "make install" fails outright. Packaging is unaffected, because the spec exports INSTALL_LOG, which already routes $(INSTALL) through "pkg.sh log-install"

Route the remaining $(INSTALL) defaults through $(LOG_INSTALL_SH) as well to address the failures: $(SUDO) jw.pkg log-install -p for DEVELOPMENT=false, plain jw.pkg log-install otherwise. Move -f $(PKG_FORMAT) out of $(LOG_INSTALL_SH) and into the two logging call sites, so the no-log paths don't carry a package format they never use.

pkg.sh: log-install: Don't log by default

cmd_log_install() defaults $c_logfile to "install.log", so every invocation without -l appends to an install.log in the current directory. That's semantical nonsense.

Default $c_logfile to empty instead. The existing empty-$c_logfile early exit already skips logging, so no -l now means no log, and callers that want a log pass -l explicitly, as the packaging flow does through INSTALL_LOG.

conf / scripts: Fix unprivileged "make install"

Unprivileged "make install" currently returns an error. That looks bad.

It actually is not a real problem, because unprivileged "make install" installs files into locations that are good for nothing, in the sense that they don't constitute a meaningful or usable hierarchy of installed files. Debugging / inspecting the install machinery itself is a valid use case, though, and it's easier to explain to the unsuspecting user that unprivileged installation is something akin to shooting range training than why "make install" outright errors out, so fix the error messages.

This PR fixes errors during "make install" as unprivileged user. It does little more than installing files into a fake root environment which in itself is not useful for anything meaningful. But users seeing errors during "make install" will understandably assume that something is very off, so this PR just fixes the errors. #### defs.mk: Don't use plain /usr/bin/install In a development tree, $(INSTALL) falls back to plain install(1), which refuses dead symlinks, so unprivileged "make install" fails outright. Packaging is unaffected, because the spec exports INSTALL_LOG, which already routes $(INSTALL) through "pkg.sh log-install" Route the remaining $(INSTALL) defaults through $(LOG_INSTALL_SH) as well to address the failures: $(SUDO) jw.pkg log-install -p for DEVELOPMENT=false, plain jw.pkg log-install otherwise. Move -f $(PKG_FORMAT) out of $(LOG_INSTALL_SH) and into the two logging call sites, so the no-log paths don't carry a package format they never use. #### pkg.sh: log-install: Don't log by default cmd_log_install() defaults $c_logfile to "install.log", so every invocation without -l appends to an install.log in the current directory. That's semantical nonsense. Default $c_logfile to empty instead. The existing empty-$c_logfile early exit already skips logging, so no -l now means no log, and callers that want a log pass -l explicitly, as the packaging flow does through INSTALL_LOG. #### conf / scripts: Fix unprivileged "make install" Unprivileged "make install" currently returns an error. That looks bad. It actually is not a real problem, because unprivileged "make install" installs files into locations that are good for nothing, in the sense that they don't constitute a meaningful or usable hierarchy of installed files. Debugging / inspecting the install machinery itself is a valid use case, though, and it's easier to explain to the unsuspecting user that unprivileged installation is something akin to shooting range training than why "make install" outright errors out, so fix the error messages.
In a development tree, $(INSTALL) falls back to plain install(1), which
refuses dead symlinks, so unprivileged "make install" fails outright.
Packaging is unaffected, because the spec exports INSTALL_LOG, which
already routes $(INSTALL) through "pkg.sh log-install"

Route the remaining $(INSTALL) defaults through $(LOG_INSTALL_SH) as
well to address the failures: $(SUDO) jw.pkg log-install -p for
DEVELOPMENT=false, plain jw.pkg log-install otherwise. Move -f $(PKG_FORMAT)
out of $(LOG_INSTALL_SH) and into the two logging call sites, so the
no-log paths don't carry a package format they never use.

Signed-off-by: Jan Lindemann <jan@janware.com>
cmd_log_install() defaults $c_logfile to "install.log", so every
invocation without -l appends to an install.log in the current
directory. That's semantical nonsense.

Default $c_logfile to empty instead. The existing empty-$c_logfile
early exit already skips logging, so no -l now means no log, and
callers that want a log pass -l explicitly, as the packaging flow
does through INSTALL_LOG.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M (pi)
Signed-off-by: Jan Lindemann <jan@janware.com>
conf / scripts: Fix unprivileged "make install"
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 3m33s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m46s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m36s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m46s
CI / Packaging test (push) Successful in 0s
6da6ac2505
Unprivileged "make install" currently returns an error. That looks bad.

It actually is not a real problem, because unprivileged "make install"
installs files into locations that are good for nothing, in the sense
that they don't constitute a meaningful or usable hierarchy of installed
files. Debugging / inspecting the install machinery itself is a valid
use case, though, and it's easier to explain to the unsuspecting user
that unprivileged installation is something akin to shooting range
training than why "make install" outright errors out, so fix the error
messages.

Signed-off-by: Jan Lindemann <jan@janware.com>
Jan Lindemann scheduled this pull request to auto merge when all checks succeed 2026-08-18 17:27:34 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
janware/jw-pkg!71
No description provided.