Re: nosh version 1.33

From: Guillermo <>
Date: Mon, 17 Apr 2017 20:05:17 -0300

2017-04-09 16:52 GMT-03:00 Jonathan de Boyne Pollard:
> The nosh package is now up to version 1.33 .
> [...]
> More packages
> -------------
> There are now four more -shims packages, for commands whose names conflict with
> commands from other packages: nosh-kbd-shims, nosh-bsd-shims, nosh-core-shims,
> and nosh-execline-shims.

Is this so that package managers can alert users when they try to
install packages with these conflicts? If yes, then the
nosh-execline-shims* packages should also have fdmove(1) and exec(1).
I'm aware that the latter is special because it is the name of one of
the binaries created by the build system (and conveniently allows one
to get a compile-time implementation of setlock(1) by performing
'./exec setlock'); I manage to install both nosh and execline on my
own machine by installing nosh's exec binary as /bin/nosh and making
/lib/nosh/exec a link to /bin/nosh (among other tweaks), so that
/bin/exec is the execline program. The 'chain to a different
personality of the same binary' magic going on inside exec_terminal()
even spares me from having to prepend /lib/nosh to PATH or using
absolute paths inside nosh scripts :)

I'm surprised that if this route is being taken, there aren't any
nosh-daemontools-shims* packages, or something like that, containing
envdir, envuidgid, setlock, setuidgid, softlimit, svc, svok, svscan,
svstat, svup, tai64n and tai64nlocal. AFAICS, Debian, the Arch User
Repository (AUR) and Gentoo all have a daemontools package with
conflicting names after all (and both the AUR and Gentoo also have a
daemontools-encore package).

I'm also looking at the recent package/stage script. It seems that
every program and program alias created by package/compile in
${src}/command/ is installed to some ${dest}/nosh-*/ directory,
except the aliases disable, enable, preset, reset, show and show-json,
so no binary packages will contain them. I'm not sure if this is
intentional, and it is a minor thing, but I though I should mention it
as well.

Received on Mon Apr 17 2017 - 23:05:17 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC