Hello,
the page
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
suggests to specify /run/%{name}/ directories and files in %files and then says
Files placed in the subdirectories may be listed the same way or omitted entirely as the files will be cleaned up on every reboot.
I assume it talks about subdirectories of that /run/%{name}/.
However, how about subdirectories like /run/lock/%{name}/ ?
In Fedora base container images, the /run is empty. So when you try to do
FROM fedora:23 RUN dnf install -y package-which-puts-something-to-run-lock
it will fail because there is no /run/lock there. An example is opencryptoki and
https://bugzilla.redhat.com/show_bug.cgi?id=1341079
What is the policy about specifying /run/lock/ (and in general /run/otherdirs/) subdirectories in %files?
Could the guideline be amended to explicitly say that anything under /run/ which is not under /run/%{name}/ should not be listed in %files?
Thank you,
Jan Pazdziora wrote:
Hello,
the page
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
suggests to specify /run/%{name}/ directories and files in %files and then says
Files placed in the subdirectories may be listed the same way or omitted entirely as the files will be cleaned up on every reboot.
I assume it talks about subdirectories of that /run/%{name}/.
However, how about subdirectories like /run/lock/%{name}/ ?
In Fedora base container images, the /run is empty. So when you try to do
FROM fedora:23 RUN dnf install -y package-which-puts-something-to-run-lock
it will fail because there is no /run/lock there. An example is opencryptoki and
https://bugzilla.redhat.com/show_bug.cgi?id=1341079
What is the policy about specifying /run/lock/ (and in general /run/otherdirs/) subdirectories in %files?
Could the guideline be amended to explicitly say that anything under /run/ which is not under /run/%{name}/ should not be listed in %files?
I've always been of the firm opinion that in general all files should be "owned", e.g. that rpm -q -f /path/too/foo can tell you the owner. So, I would argue against the amendment you suggest.
Offhand, what seems to be the real problem here is the lack of /run/lock in the container images. I'd consider that a bug worth fixing. Is that not possible?
-- Rex
Rex Dieter wrote:
Jan Pazdziora wrote:
Hello,
the page
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
suggests to specify /run/%{name}/ directories and files in %files and then says
Files placed in the subdirectories may be listed the same way or omitted entirely as the files will be cleaned up on every reboot.
I assume it talks about subdirectories of that /run/%{name}/.
However, how about subdirectories like /run/lock/%{name}/ ?
In Fedora base container images, the /run is empty. So when you try to do
FROM fedora:23 RUN dnf install -y package-which-puts-something-to-run-lock
it will fail because there is no /run/lock there. An example is opencryptoki and
https://bugzilla.redhat.com/show_bug.cgi?id=1341079
What is the policy about specifying /run/lock/ (and in general /run/otherdirs/) subdirectories in %files?
Could the guideline be amended to explicitly say that anything under /run/ which is not under /run/%{name}/ should not be listed in %files?
I've always been of the firm opinion that in general all files should be "owned", e.g. that rpm -q -f /path/too/foo can tell you the owner. So, I would argue against the amendment you suggest.
Offhand, what seems to be the real problem here is the lack of /run/lock in the container images. I'd consider that a bug worth fixing. Is that not possible?
To expand on that, one fix would be to ensure /run/lock is "owned", currently it is not. filesystem owns /var/lock, /var/run and /run, so adding /run/lock there too could be a possibility.
-- Rex
On Mon, Jun 06, 2016 at 11:46:49AM -0500, Rex Dieter wrote:
Offhand, what seems to be the real problem here is the lack of /run/lock in the container images. I'd consider that a bug worth fixing. Is that not possible?
I guess it is possible. I just thought the container content is supposed to be minimal on purpose but if the general agreement is that this is a bug and the directori should be there, I sure will file it as a bug against the base image.