Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

2019-12-03 Thread Casper Ti. Vector
On Sun, Dec 01, 2019 at 09:47:52PM -0500, Steve Litt wrote:
> Would it be acceptable to you and them to put the binaries in /bin/s6
> and then very early in the boot add /bin/s6 to the path? This isn't a
> lot different from what djb did with /command, except it's not off the
> root, which everyone seems to hate.

Or can we consider the Plan 9 style [1], which searches all relative
paths (in the broad sense, i.e. all which do not begin with `/', `./' or
`../') from $PATH, so we can install chainloaders into /bin/s6 and then
use `s6/cd' to run `/bin/s6/cd' in execline?

[1] 

I fully understand that this convention is not followed in most Unix
shells (except for rc(1) which is from Plan 9, and perhaps some others),
but execline is not a shell, and we can additionally symlink /bin/s6/*
into /bin for backward compatibility.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



Re: s6 usability

2019-12-03 Thread Steve Litt
On Mon, 2 Dec 2019 17:17:50 -0600
Samuel Holland  wrote:

> On 12/2/19 3:32 PM, Laurent Bercot wrote:
> >> As a guy who has both daemontools and s6 installed on the same
> >> box, I thank you from the bottom of my heart for:
> >>
> >> 1) Prepending s6- to each command so they don't clash with djb's
> >> 2) Except for the s6-, naming them the same as djb's so I have
> >> less to remember.  
> > 
> > Yes, there are a good number of people, me included, who prefer that
> > naming scheme. However, Jan's UX return is valid, and if I want to
> > make s6 adoption as easy as possible, it needs to be taken into
> > account too.  
> 
> From a Linux distribution perspective, there's also the question of
> if s6 can be made a drop-in replacement for daemontools, since it
> does follow djb's naming scheme. In gentoo, there are various
> packages that depend on virtual/daemontools; for example, the
> nullmailer test suite uses ipcserver. From a quick comparison of the
> documentation, it looks like s6 only adds options, and remains
> compatible with the daemontools options.
> 
> So would it be valid/acceptable for a distribution to create
> unprefixed symlinks to the s6-* binaries? It looks like this would
> mostly only work for the subset of the binaries that implement
> daemontools functionality; some others (s6-setsid, s6-sudo) would
> have naming conflicts if they were not prefixed.
> 
> Then, with the symlinks, s6 could "provide" virtual/daemontools.
> Maybe this would also help discoverability (the issue at hand). Maybe
> the inconsistency would cause more harm than good, and the symlinks
> should be "for compatibility only".
> 
> Thoughts?

In my opinion, 99% of all people currently using daemontools are highly
technically proficient and could easily either rename commands or
prepath to a directory containing prefixless symlinked synonyms. IMHO
if the distro does it, they'll find a way to screw it up. And even if
the distro does it right, it will screw that 1 in a million people
(like me) who occasionally use daemontools and s6 on the same box,
switching between them regularly.

Personally, I'd leave well enough alone.

SteveT

Steve Litt 
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21