'systemd-tmpfiles --create' is not called when installing #955
Comments
I think the binary was built as expected and the problem is that the Do you have systemd-tmpfiles(8) ? |
|
|
HarryMichal
added
2. Build System
|
Yes, Running the command So, if I understand correctly, Thanks for the help! |
|
It actually should be possible to run the command from the build system, yes. Is that something we want to do? @debarshiray |
We only need to invoke
So, yes, we should invoke |
That will solve this exact problem but won't be compatible with #840. There the final binary is used to create the completions scripts. But maybe some other way could be found for that particular problem. I'll put together a PR for this. |
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source, and not when using a downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the package is later downloaded and installed
by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
containers#955
|
Does #965 help? |
|
Yes, I tried it and it works. It creates the symlink on the install step. Thanks! |
Add solution mentioned in containers/toolbox#955. Addeed version of meson build as most system package manager (apt) come with older meson version.
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source, and not when using a pre-built binary
downstream package, because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
containers#955
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] mesonbuild/meson#9
containers#955
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] mesonbuild/meson#9
containers#955
debarshiray
changed the title
Describe the bug
On Ubuntu 20.04, toolbox version 0.0.99.3 builds and installs but fails to execute with:
File exists:
The interpreter for the binary seems to be incorrect
The interpreter file doesn't exist on my system:
Steps how to reproduce the behaviour
meson setup -Dprofile_dir=/etc/profile.d builddirmeson-setup.logmeson compile -C builddirmeson-compile.logsudo meson install -C builddirmeson-install.logtoolbox --helpExpected behaviour
Toolbox builds, installs, and runs correctly.
Actual behaviour
Toolbox builds and installs correctly but does not run.
Output of
toolbox --version(v0.0.90+)Toolbox package info (
rpm -q toolbox)Installed from source.
Output of
podman versionPodman package info (
rpm -q podman)Info about your OS
Ubuntu 20.04
Additional context
Toolbox 0.0.99.2 builds, installs, and runs correctly with the same build process.
Interpreter for 0.0.99.2 appears to be correct.
Meson installed in virtualenv via pip
Python3 from package manager
Ninja from package manager
Go from package manager
(using newer version with update-alternatives:
sudo update-alternatives --install /usr/bin/go go /usr/lib/go-1.16/bin/go 100 --slave /usr/bin/gofmt gofmt /usr/lib/go-1.16/bin/gofmt)The text was updated successfully, but these errors were encountered: