The page https://fedoraproject.org/wiki/Packaging:Tmpfiles.d talk about putting /run/%{name}/ to %files and 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.
The ticket https://fedorahosted.org/fesco/ticket/525 again says that the files should be defined as normal files.
These days, /var/lock is a symlink to ../run/lock.
In base container image of Fedora, /run/lock does not exist:
$ docker run fedora:23 ls -la /run total 12 drwxr-xr-x. 3 root root 4096 Jun 6 07:02 . drwxr-xr-x. 18 root root 4096 Jun 6 07:02 .. drwxr-xr-x. 2 root root 4096 Jun 6 07:02 secrets
Installing any package which specifies something under /var/lock in %files then fails. For an example, see opencryptoki and
https://bugzilla.redhat.com/show_bug.cgi?id=1341079
But really, what is the point of defining the files and directories in %files when they won't be present due to the use of tmpfs (unless they are defined in tmpfiles and that's a mechanism orthogonal to the rpm database)?
As for implementation recommendation, it's either possible to make recommendation for adding these parent directories to base container images of Fedora, or make recommendation against specifying the files and directories under %files.
I've tried to get some opinion on the devel mailing list
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U2R34HF2IYWX7CVNONIW7HIKIQTYPBKN/
but did not get any responses there.
I've filed https://fedorahosted.org/fesco/ticket/1585 but Kevin suggested I try FPC.
No longer on fpc, but to answer your question "what is the point of defining the files and directories in %files when they won't be present due to the use of tmpfs", I'm 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. This has some other nice technical benefits, but no need to go more into that here.
What seems to be a primary problem here is the lack of /run/lock in the container image, offhand, I'd consider that a bug worth fixing.
(I'll try to followup onlist saying basically the same thing)
Understood. But for that %ghost is probably the best approach, isn't it?
I was pointed to one use case when having the file (and the directory) in rpm is useful -- when the package is installed and it immediately needs to be used, without tmpfiles being invoked.
I just wanted to point out that the fesco ticket mentioned above is something like six years old. The guideline for tempfiles.d has changed since them. I'm not sure why anyone would think it relevant that what's referenced in the guideline differs from what's in the old fesco ticket.
I don't see a conflict between the FESCO ticket and https://fedoraproject.org/wiki/Packaging:Tmpfiles.d -- I merely referenced that FESCO ticket to show what the current packaging guideline seems to be based on.
If you have a suggested diff for the tmpfiles.d page, that'd be a helpful starting point.
I don't think I have a diff to propose. At this point I'm looking for consensus rather than actual wording.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-06-23/fpc.2016-06-23-16.00.txt):
...another workaround I remembered is that if all the packages which own dirs. in /run/lock also own /run/lock that will fix things.
Replying to [comment:10 james]:
Who is the needinfo aimed at?
Replying to [comment:9 james]:
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-06-23/fpc.2016-06-23-16.00.txt): 629 Handling dirs. under /var/lock and /var/run in %files and images (geppetto, 16:43:00) ACTION: Do minor cleanup of /var/run and /var/lock to /run and /run/lock (+1:5, 0:0, -1:0) (geppetto, 17:05:28)
Could you elaborate what this means and what it should achieve?
LINK: https://fedorahosted.org/fpc/ticket/439 has a comment about %ghost being ill-advised (orionp, 17:05:52) You can ask systemd package that owns the tmpfiles.d conf. for /var/lock to also have it in %files (geppetto, 17:16:22)
The symlink is owned by filesystems (filesystem-3.2-37.fc24.x86_64). How does adding ownership to systemd improve the situation of Docker base image?
Also ping the upstream container tools about fixing their tools for this issue. (geppetto, 17:16:53)
What is the proposed fix?
Metadata Update from @adelton: - Issue assigned to james
So after the pagure migration I'm trying to clean up all of the open FPC ticket. And I have very little idea of what to do with this one.
This ticket was put into needinfo state because basically the committee can't really proceed beyond the minor cleanups we agreed to do and so we need either a draft or a concrete proposal or something we can consider. We just don't have the manpower to write all of those things ourselves. And there aren't that many states a ticket could go into; needinfo fit, so that's where it went.
I think the question asked in the previous content were all answered in the meeting logs starting at https://meetbot.fedoraproject.org/fedora-meeting-1/2016-06-23/fpc.2016-06-23-16.00.log.html#l-125
We noticed the guidelines referenced the old locations for things and so we added an action item to clean them up. It would achieve… more clean-up-edness(?).
The symlink is owned by filesystems (filesystem-3.2-37.fc24.x86_64). How does adding ownership to systemd improve the situation of Docker base image
But there's also something which in some cases creates it dynamically, right? Isn't that part of what this ticket is all about?
The problem here is that someone who knows all about docker and containers and such is coming to a group who, by and large, doesn't have that expertise and then asking us for the solution to problems that are only seen with docker and containers and such, and not presenting a concrete solution. So we've tried to do what we can, but obviously it wasn't sufficient. And, well, someone's going to have to actually make a concrete and actionable proposal.
I also have no memory of whether I actually did clean up all mentions of /var/run and /var/lock, so I'll go search for that now.
Metadata Update from @tibbs: - Issue close_status updated to: None
There was one remaining reference to each of /var/run and /var/lock, which fixed.
Metadata Update from @tibbs: - Issue tagged with: needinfo
So this been without answer for 2 years... I think we don't need to have this opened anymore.
Metadata Update from @ignatenkobrain: - Issue close_status updated to: nothingtodo - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.