Problem: can't install additional files via project.xml

[vyskocilm]

Solution: introduce zinstall, the zero model for file installation

The beauty of this model (as opposite of PR#539) is that it impose clear
protocol between model and rest of the generators. This protocol are
files in builds/zinstall/, which are then included in generated files.

This has two main advantages over older attempts

1. installation model fully implemented in ONE place
2. because of the protocol, there can be more models w/o any impact on
   backend

Design goals are stated in README.txt, but let's repease

1. KISS - the less options the better
2. No conditionals - please don't create an another half-baked XML
   programming langugage like ant
3. Real problems - don't add more options because you can
   ... or you will get replaced by zinstall2 ;-)

foundation for closing #810

cc @bluca @sappo @jimklimov @karolhrdina

extra-cc @hintjens - sorry, but I was so slooow with solving this :-(

[vyskocilm]

I must say I am extremly proud of it! I wanted to create something like zinstall project initially. This design goal have helped me to streamline the implementation and to define builds/zinstall protocol. I am sure that pieter would love it. Unlike my initial attempt. Some lessons take their time!

[bluca]

Thanks, this is a very interesting idea! Let's see how it works out in the various projects

[sappo]

@vyskocilm this looks like magic to me. Can you explain to me what's happening? Does the user have to manually create the files in the zinstall directory?

[sappo]

@vyskocilm I've taken a closer look at your code and the name zinstall is very deceiving as you're not installing anything but merely providing code snippets to be inserted somewhere else. I'm not convinced yet because I don't understand the Problem. Let's start by what are systemd tempfiles? And why do I need them in zproject?

[vyskocilm]

@sappo - I made an example in a meanwhile, see https://github.com/vyskocilm/zinstall/tree/master/builds/zinstall

[vyskocilm]

@sappo maybe it'd be better to have design discussion elsewhere, but well

Our problem is that our daemons store their state as a plain files in some runtime directory, which is somewhere in /var/lib/$project/$daemon. So normally there's no way how daemon can create it in runtime. And I belive expecting daemon to create own runtime dir is against all the modern expectations for containers and so. Our solution is to distribute systemd-tmpfiles.d config file, so the runtime directory will be managed by systemd.

Zproject itself has no capability to express installation of additional files. Mainly because it's not an easy problem to solve. See the #539 how ugly was my previous attempt to solve it. It was implemented everywhere in project and as we've have three generations/iterations of approach, those were handled everywhere. This is an attempt to solve this problem again, but without adding too much burden to the rest of zproject scripts. The zinstall_include lines are the protocol between scripts and install model(s).

Note that zproject_install.gsl is not limited to this type, it can be extended. But as this the real problem we're facing, zproject_install.gsl solve excactly this and nothing more.

BTW: if you don't like builds/zinstall - well, naming is a hard problem, so I'll welcome your pull requests ;-)

BTW2: I found our original design discussion with Pieter - #373