Re: nosh version 1.37

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sun, 18 Feb 2018 18:23:05 -0300

2018-02-18 3:49 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.37 .
> [...]
> Per-user management has been augmented, finally fixing the problem
> of |system-control| locating the per-user manager by giving the
> per-user manager an optional listening FIFO open file descriptor,
> which it uses to listen for user-wide state change commands.
> |system-control --user| |halt|/|normal|/|sysinit|/&c. now send
> commands via this FIFO, and each user's |user-services_at_/username/|
> service bundle now uses |fifo-listen| to set up the FIFO and creates
> the |per-user-manager/| subdirectory in |/run/user|.

\O/ \O/ \O/

On the other hand, all those new .do scripts that generate systemd
unit files and configuration files using the read_os shell function
fail on Gentoo :-P

redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done.
redo-ifchange[2]: ERROR: services/dbus-daemon.service: Not done.
redo-ifchange[2]: ERROR: services/system-wide.conf: Not done.
redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done.
redo-ifchange[2]: ERROR: convert/per-user/at-spi-dbus-bus.service: Not done.
redo-ifchange[2]: ERROR: convert/per-user/gconfd.service: Not done.
redo-ifchange[2]: ERROR: convert/per-user/per-user.conf: Not done.

'read_os ID' returns 'gentoo' for Gentoo's /etc/os-release, and
'read_os VERSION_ID' returns nothing (it is a rolling release
distribution), so this always matches the

*) ext=who ;;

lines, making the redo-ifchange invocation fail with either "Don't
know what to use to build this" or "Cannot find .do file to use". Or
making it call convert/per-user/default.do and *then* failing. So what
do I do, should I patch the .do scripts to include a 'gentoo:*)' line?

This is going to happen for every [GNU/]Linux distribution that is not
Debian, Arch, CentOS or RHEL. It does not... uh... look very portable
:/

Additionally, the convert/per-user/*.do scripts' 'read_os' function
calls 'exec' via absolute path /bin/exec instead of relative path
../../exec, which is not going to work if nosh isn't already installed
(chicken and egg). On my computer that results in accidentally calling
execline's exec program, which is even funnier.

Thanks for your attention.
G.
Received on Sun Feb 18 2018 - 21:23:05 UTC