Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Tue, 16 Jan 2018, Jonathan de Boyne Pollard wrote:

> Charlie Brady:
> 
> > Sorry, doesn't work for me:
> >
> You need a POSIX-conformant system with all of the POSIX utilities, including
> |pax| .

OK, so this statement is incomplete:

"It requires redo to build, and builds with the g++ and clang++ 
compilers".

Perhaps you should use "or" there, rather than "and". Both compilers 
aren't required, IIUC.

And the build doesn't fail gracefully. There is no indication that the 
build failed for lack of "pax".

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

You have prompted me to fill in a long-standing dangling hyperlink.

* http://jdebp.eu./FGA/slashpackage.html


 If I may add my two cents: I think you're mixing two very different
things in this page.

 There is the slashpackage convention for installed packages, i.e.
visibility of executables in /package/category/name/command/name
and the like. I find it useful; and my software *still follows* that
convention, if compiled with --enable-slashpackage.

 And there is the internal structure for building packages, which is
package/compile, package/run, etc. I liked its simplicity at first,
but with experience, I found that it wasn't ideal.

 The primary issue is that it's inherently not cross-compile-friendly.
Having a pre-written compilation script makes it difficult to separate
gathering information about the target and actually building for the
target; whereas a configure/make system can frontload the data
gathering operation. (And in my case I frontload it all in the
skalibs package, so when the annoying part of finding correct sysdeps
for the target has been done once, all the rest of the software
cross-compiles effortlessly.)

 A secondary issue is that system administrators and distribution
packagers, i.e. the intended users of the build system, just could
not stop complaining about it, to the point that complaints about the
build system were for some time the majority of the mailing-list's
traffic. No matter whether their reasons were good or bad, if the
intended users of an interface don't like the interface, then it's
probably a good idea to change the interface. Since switching to
configure/make, the popularity of s6 has skyrocketed; I don't think
it's entirely accidental.

 So yes, the internal package/compile build system is something I
stepped away from. But IMO that's not at all the important part of
the "slashpackage convention", one does not imply the other; and
I wish you would emphasize that.

--
 Laurent

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[multiplexd]

On Tue, Jan 16, 2018 at 08:06:09AM +, Jonathan de Boyne Pollard wrote:
> You have prompted me to fill in a long-standing dangling hyperlink.
> 
> * http://jdebp.eu./FGA/slashpackage.html
> 

Ah, good to hear! I've been waiting for that page to be written for a 
while :).

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Charlie Brady:


Sorry, doesn't work for me:

You need a POSIX-conformant system with all of the POSIX utilities, 
including |pax| 
.  
The Debian |package/debian/control| file automatically ensures this on 
Debian, with its |Build-Depends:| information.  The BSDs have these 
tools /as standard/ in the base operating system, out of the box.  
Thomas Caravia both notes this in the Archnosh doco (in the section 
headed "Dependencies") and declares it as a |makedepends| in the 
|PKGBUILD| itself so that it is automatically ensured on Arch.  You are 
going to have to do this yourself on your operating system, too.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Thomas Caravia:


I'm not familiar with rpm but my packaging is just this:


You have prompted me to fill in a long-standing dangling hyperlink.

* http://jdebp.eu./FGA/slashpackage.html

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Mon, 15 Jan 2018, Thomas Caravia wrote:

> I'm not familiar with rpm but my packaging is just this:
> 
> 1) package/compile: you'll need "redo" to build

Sorry, doesn't work for me:

bash-4.2$ package/compile 
redo: ERROR: all: Cannot find .do file to use.
bash-4.2$ sh -ex package/compile
+ '[' '!' -d package ']'
+ '[' '!' -d source ']'
+ ./package/prepare
+ ./package/make
redo: ERROR: all: Cannot find .do file to use.
bash-4.2$ 

The redo build works, but isn't perfect either:

bash-4.2$ package/compile
./package/tools: line 17: type: clang++: not found
redo.cpp: In function void read_db_line(std::istream&, Information&, 
std::string&):
redo.cpp:394:14: warning: unused variable c [-Wunused-variable]
  switch (int c = s.get()) {
  ^
popt.cpp: In member function virtual void popt::table_definition::help():
popt.cpp:147:13: warning: unused variable short_name [-Wunused-variable]
if (char short_name = n->query_short_name()) l += 2;
 ^
popt.cpp:149:14: warning: unused variable short_name [-Wunused-variable]
 if (char short_name = n->query_short_name()) l += 1;
  ^
popt.cpp:162:14: warning: unused variable short_name [-Wunused-variable]
 if (char short_name = n->query_short_name()) t += "|";
  ^
bash-4.2$ 

Build platform is Fedora linux.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

 Note that s6 has been using a configure/make/sudo make install
building scheme since 2014, and supports FHS as well as slashpackage,
so it can be easily packaged for any distribution. :P

--
 Laurent

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Thomas Caravia]

Hello,

> > Do you know whether anyone has documented how to build on a non-Debian 
> > linux? An rpm spec file would be ideal, but just simple non-Debian 
> > centric build instructions would be better than nothing.
> 
> Thomas Caravia constructed the Archnosh PKGBUILD the same way. It does 
> the slashpackage-style build, then takes the built slashpackage-style 
> package and parcels it out into a set of Arch binary packages, with a 
> light dusting of patches to a handful of service bundles.  It even 
> mostly re-uses the Debian maintenance scripts.

I'm not familiar with rpm but my packaging is just this:

1) package/compile: you'll need "redo" to build

2) package/stage: you can tweak this script to fit your distribution's
filesystem hierarchy

3) use the resulting package trees for your packaging: in my case
one-for-one copying

4) include install/upgrade/remove scripts from package/debian for the
packages that need them

Service bundle patches account for differences in paths or usernames
with Archlinux, when I find them.

> (On that note, Thomas: You may enjoy the start that I have made in 1.37 
> to a _Packages and Ports_ chapter in the /nosh Guide/.  Yes, I currenly 
> plan for the |.p|/|.func| system to get at least a short mention.)

It did not go unnoticed!

Regards,
Thomas

Re: Incompatibilities between runit and s6?

[Laurent Bercot]

Thanks. I would rather you write one small unit file then me needing to
write ten or fifteen of them.


 Done.
 https://skarnet.org/software/s6/s6-svscan-not-1.html#systemd

 I did not follow Jonathan's suggestion to use a .path unit file,
because the other examples on this page assume that the scandir
is already present at boot time, and there's no need to burden
the poor system with one more inotify watch. :)

--
 Laurent

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

The |service-manager| manual page from version 1.37 or later of the 
nosh toolset contains  a full breakdown of the control/status API in a 
|supervise/| directory, including the daemontools-encore extensions 
and the nosh service-manager's own extensions.  I am hoping to get 
version 1.37 released within the next week.  In the meantime, I have 
pushed the new manual page to the on-line copy of the /nosh Guide/ 
.  You can find the HTML-form 
manual page for |service-manager| hyperlinked from several pages in 
the /Guide/, including the _new Interfaces_ page.



Charlie Brady:

Do you know whether anyone has documented how to build on a non-Debian 
linux? An rpm spec file would be ideal, but just simple non-Debian 
centric build instructions would be better than nothing.


Yes.  I have.  The slashpackage-style build instructions, which are of 
course /not/ Debian-specific nor even /Linux-/specific, are actually 
right there on the source package WWW page.


The only thing that is Debian-specific is the step that gets one from a 
/built/ slashpackage-style package to Debian binary packages.  This is 
in the supplied |package/debian/rules| command.  But even that is not 
actually Debian-specific, as there is a similar |package/bsd/rules| 
command that does the same thing on the BSDs.


Thomas Caravia constructed the Archnosh PKGBUILD the same way. It does 
the slashpackage-style build, then takes the built slashpackage-style 
package and parcels it out into a set of Arch binary packages, with a 
light dusting of patches to a handful of service bundles.  It even 
mostly re-uses the Debian maintenance scripts.


(On that note, Thomas: You may enjoy the start that I have made in 1.37 
to a _Packages and Ports_ chapter in the /nosh Guide/.  Yes, I currenly 
plan for the |.p|/|.func| system to get at least a short mention.)


I was only expecting you to read the manual for doco on the common 
control/status API that you were interested in, not build the software.  (-:

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Charlie Brady:

There is a certain level of compatibility between daemontools and 
runit, and I presume the same exists for s6. The devil is in the detils.


The |service-manager| manual page from version 1.37 or later of the nosh 
toolset contains  a full breakdown of the control/status API in a 
|supervise/| directory, including the daemontools-encore extensions and 
the nosh service-manager's own extensions.  I am hoping to get version 
1.37 released within the next week.  In the meantime, I have pushed the 
new manual page to the on-line copy of the /nosh Guide/ 
.  You can find the HTML-form manual 
page for |service-manager| hyperlinked from several pages in the 
/Guide/, including the _new Interfaces_ page.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

I've started thinking that I wouldn't need to abandon use of 'sv'. With
both runit and s6 installed, and a supervision tree of s6-svscan and
s6-supervise processes, I suspect that 'sv t ...' would still work. 'sv
status ...' on the other hand might not. I would need to study the 
control

fifo protocol and status file layout to be sure.


 sv status will not work, because the status file has a different
format in s6 and in runit.
 sv t and others? It may work; it may not. If you try this, it's on
you: the interface between s6-svc and s6-supervise is not public and
is not guaranteed stable. Generally speaking, using the tools of one
supervision suite on another one isn't something I think is worth
spending effort on.

--
 Laurent

Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Thu, 11 Jan 2018, Charlie Brady wrote:

> On Wed, 10 Jan 2018, Avery Payne wrote:
> 
> > I am guessing the differences will be subtle, and most of the general
> > behavior you desire will remain the same.  You may be able to get a way
> > with a "sed 's/sv\ /s6-sv\ /' new-script-name" on some of
> > your scripts; give it a try, what could it hurt?
> 
> That would fail because, eg, 'sv t xxx' needs to become 's6-svc -t xxx'.  

I've started thinking that I wouldn't need to abandon use of 'sv'. With 
both runit and s6 installed, and a supervision tree of s6-svscan and 
s6-supervise processes, I suspect that 'sv t ...' would still work. 'sv 
status ...' on the other hand might not. I would need to study the control 
fifo protocol and status file layout to be sure.

Again, has anyone else considered these things and can offer an opinion? 
Are the differences documented anywhere? There is a certain level of 
compatibility between daemontools and runit, and I presume the same exists 
for s6. The devil is in the detils.

Re: Incompatibilities between runit and s6?

[Jonathan de Boyne Pollard]

Laurent Bercot:

Also, admittedly, I simply did not want to read the systemd unit file 
documentation to understand how to start a s6 supervision tree from 
systemd. I will do the effort and come up with a small unit file 
suitable for this.




* https://lists.debian.org/debian-user/2014/09/msg01715.html

* http://jdebp.info./FGA/inittab-is-history.html

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752075#82

Re: Incompatibilities between runit and s6?

[Charlie Brady]

On Wed, 10 Jan 2018, Laurent Bercot wrote:

> >If you are a systemd user, chances are you do not need s6.
> >
> >Really? So all the criticism of systemd is bunkum?
> 
>  :) I need to update this page.
>  What this means is that systemd does provide a supervision
> infrastructure, so for people stuck with systemd, it's okay to use what
> their system provides, and s6 is redundant there. This does not mean
> that all my systemd criticism is invalid.
> 
>  Also, admittedly, I simply did not want to read the systemd unit file
> documentation to understand how to start a s6 supervision tree from
> systemd. I will do the effort and come up with a small unit file
> suitable for this.

Thanks. I would rather you write one small unit file then me needing to 
write ten or fifteen of them.

I agree with you about the systemd unit file documentation. That's exactly 
why I still need runit or s6. Well, one of the reasons.

re: Incompatibilities between runit and s6?

[Charlie Brady]

On Wed, 10 Jan 2018, Avery Payne wrote:

> I am guessing the differences will be subtle, and most of the general
> behavior you desire will remain the same.  You may be able to get a way
> with a "sed 's/sv\ /s6-sv\ /' new-script-name" on some of
> your scripts; give it a try, what could it hurt?

That would fail because, eg, 'sv t xxx' needs to become 's6-svc -t xxx'.  

> Also, for those systems not running CentOS, what are you currently using
> for init + service management?

That's actually a null set, except for some old embedded systems running 
busybox init+runit.

re: Incompatibilities between runit and s6?

[Avery Payne]

I am guessing the differences will be subtle, and most of the general
behavior you desire will remain the same.  You may be able to get a way
with a "sed 's/sv\ /s6-sv\ /' new-script-name" on some of
your scripts; give it a try, what could it hurt?

Also, for those systems not running CentOS, what are you currently using
for init + service management?