Okay! all great then.

Now I want us to iterate upon the suggested plan / 'road-map'. I have
hinted that we can use ADD. That is another kind of improvement. I
think it will save us some considerable overheads, if we move around
our code a bit. And actually not need to make any special s6-base
images for the remaining distros.

The idea is that with a docker-targeted s6 tarball, it should
universally work on top of any / all base image. If what Laurent says
is true that the s6 packages are entirely self-contained. So it should
'just work' if we put the right things in the tar ball.

It can be centrally maintained in one place. No need for us to have to
duplicate the same thing in multiple distros. And in multiple versions
of each distro  (e.g. sid, wheezy). Yet every one of those we can
still support.

I also dropping off (remove) those previous points which John didn't like.
So the revised roadmap would look something like this:

* re-write /init from bash ---> execline
* add the argv[] support for CMD/ENTRYPOINT arguments
* move /init from ubuntu base image --> s6-builder
* create new 's6docker' build product in s6-builder, which contains:
  * execline.tar.gz
  * s6.tar.gz
  * /init (probably renamed to be 's6-init' or something like that)
* replace 'moved' bits in Gorak's pre-existing ubuntu base image
* document how to use it
* blog about it

How we use it:

When s6-builder runs it's builds, it can spit out 1 new extra build
target to this location:


1 single unified tarball called "s6-docker-"
(or whatever we should call it).

That 1 tarball contain all necessary s6 files required to be used in docker.
Then we can just document by telling people to put this in their Dockerfile:

FROM: debian:wheezy
ADD: https://github.com/<...>/s6docker.tar.gz /
ENTRYPOINT: ["/s6-init", … ]

All Done!

We can just as easy specify whatever other official image in the FROM line. e.g.

FROM: alpine
ADD: https://github.com/<...>/s6docker.tar.gz /
ENTRYPOINT: ["/s6-init", … ]

Or busybox, arch linux, centos, etc. It should not matter 1 cent or
change the proceedure…

This way helps us out a lot to reduce the labor. Otherwise I guess we
are giving ourselves a rather daunting task of maintaining multiple
different base images. Each of which having multiple versions etc. And
then when upstream changes them we have to too…

Please consider the revised plan.
Many thanks

* Very happy have a crack at all of the needed development works on
that list. And submit them to gorka's repos. Although I'm not so
technically adept / familiar with this stuff yet. Therefore it may
take me a while to do all that, learning as I go, etc.

* Can't blog about it (no blog myself). So someone else can do that
later on (e.g. John). After everything is done.

* Can probably start work on the first bullet point (convert "/init"
to execline) during this weekend. Unless anyone else would rather jump
in before me and do it. But it seems not.

Possible Github Organization:

So this is another point of discussion.

A new github organisation would not be so essential anymore. At least
for "being a place to house the various s6-base images". Since there
would not be any.

Yet a github organisation can still be used in 2 other ways:

* To have an official-sounding name (and downloads URL) that never need change.

* If Laurant wants to push his core s6 releases (including the docker
specific one) onto Github. Then it would be great for him to make a
"github/s6" org with Gorak, as new home for 's6', or else a git mirror
of the official skanet.org.

Given the reduced complexity, I don't really care now if we actually
have an 's6' organisation at all. But am happy to leave such a choice
entirely up to Laurent and Gorka. I mean, if they want to do it, then
they are the official people to decide upon that. I have no personal
opinion myself (either way). As I only contribute a relatively very
minor part of works to help improve it.

Kind Regards

Reply via email to