svoj,
In the spirit of trying to avoid dynamic dependencies in bintars, should we even have this one?

I met this problem today for recent 10.1 bintar compiled on kvm-bintar-trusty-amd64 , had to use one from kvm-bintar-quantal-amd64

In my understanding WITH_SYSTEMD must be explicitly disabled for all bintar builders (assuming it is set to "auto" now).

I'm not sure about that, I remember users complain about not having systemd scripts in bintars.

Is this going to be fixed?

The bintar package is built on Trusty. Trusty does have libsystemd-daemon:

Why are you still building on Trusty?

The instructions still state:

Note: Some binary tarballs are marked '(GLIBC_2.14)' or '(requires GLIBC_2.14+)'. These binaries are built the same as the others, but on a newer build host, and they require GLIBC 2.14 or higher. Use the other binaries for machines with older versions of GLIBC installed. Run ldd --version to see which version is running on your distribution.

Others are marked 'systemd', which are for systems with systemd and GLIBC 2.19 or higher.

It is rather annoying to download just to find this issue - if you are not going to fix it perhaps you should remove the systemd tarball, or at least update the notes?

Same problem on Fedora 26, tarball 10.1 and 10.2 fail to start after upgrade from Fedora 24.

What can we do about it?

1. provide a second systemd binary tarball
2. provide only one systemd binary tarball, but build it on xenial
3. provide lots of binary tarballs, for every ubuntu/fedora/etc version

I don't think we should do 1. Three bintars is already quite confusing, fourth will not make it better.

Option 2 is the easiest but trusty users won't be able to run bintars with systemd.

Option 3 means we don't build bintars on trusty, but repackage existing debs/rpms (that we have for every platform) into bintars, and offer them from the repositories page, after the user has selected the distro. So it's a change in release scripts and in web pages. And we'll have one bintar less to build, there'll be no need to build trusty systemd bintars anymore. There will be distro-tailored bintars, but they'll be built dynamically, not as portable.

I like the idea of building bintars on specific distros and labeling/naming them as such. e.g. a centos7-bintar, an ubuntu-xenial bintar, a fedora29 bintar, and so on. The question would just be deciding which distros we provide bintars for.

For every distro where build binaries. There are rpm2targz and rpm2targz tools, your release scripts can repackage rpm/deb into bintars. Or we can do it in buildbot even. Build packages and immediately create a bintar out of _CPack_Packages. It won't even need any2targz, only tar and gzip.

The question is how to offer them without overwhelming the user. I think repositories download page could be a good fit

You mean the repo config tool? Yes, putting something there would probably work fine.

As we've later discussed, this trick won't work, because the tarball will have deb (or rpm) file layout.

To create a bintar with the correct bintar file layout, we have to build it that way.

Which, probably, means we should move systemd bintar builder from trusty to xenial.

I've added kvm-bintar-xenial-amd64 and kvm-bintar-xenial-x86 builders to buildbot. Assuming they work fine I will next remove the corresponding kvm-bintar-trusty* builders and switch the release scripts to use the new builders for the systemd bintar tarballs in future releases.

AFAIK This was fixed a while back with some changes to the systemd bintar builder.