Problem: support wanted for systemd tmpfiles to spawn data directories and other service enhancements

[jimklimov]

Solution:

• add a project tag to enable tmpfiles integration (with a generated .in template => configure/extra-dist)
• deliver the file into systemd location according to config
• in service config file (or unit file?) set the workdir to specified location
• optionally set specified username and group to own the FS objects, and add to service template to run as
• set which target milestone this service is part of (if not default multi-user)

[vyskocilm]

There was an installation model long time ago. I dropped it in #539 as it become hard to understand and messy. @hintjens told me, file installation is HARD problem and a lot of people failed to solve it. The more properties you add (I heard about groups/owners) it will become more complex and less platform independent, harder to use and impossible to use it correctly. See automake. foo_bar_SCRIPTS EXTRA_DIST, ham_BIN, .... I even have no idea why there are so many options there.

I am not saying that we should not do it, just to have a good model initially.

cc @bluca @sappo

[bluca]

I agree it could get very hairy if it becomes a matrix of various bits and pieces from build systems, packaging, etc

[vyskocilm]

@bluca take a look on #825 - maybe it's the beer what is talking instead of me, but I consider my design as briliant :-D I tried to solve this puzzle several times and ... I found the way to experiment easily and safelly w/o adding to much burden to the rest of zproject.

[jimklimov]

Not exactly continuing on-topic, but well yes, packaging is "hairy" indeed, and it is something that automated projects should automate at build-time, not generation time. For example, one (more) annoyance with practical use of zproject is that the debian/redhat/travis files are pre-generated and dependency package names are set in stone, for all distros a project might be built on. And different distros, while using similar packaging software, often use very different package names (e.g. more and more I thing that an additional travis_name for dependency packages is warranted, even if defaulted to debian_name for most packages).

And it is not a problem that zproject, or indeed any application software project (whether generated or manually crafted), should be solving alone once and for all with static files, but rather one it can well help with - e.g. with .in templates populated by configure based on what packages it actually finds on the build system and/or falls-back as hardcoded.

[vyskocilm]

BTW: see our discussion about installation model with Pieter: #373