The man-db cache files are placed in/var/cache/man now. This seems incompatible with the ostree model, so this is a proposal to move it to /usr/lib/man/cache. This is also heavily requested for image-mode
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
I kind of lost track of this CP because it was misfiled under the wrong name (I fixed that in Discourse now). Left a comment too, and will vote -1 for now because reading the proposal, I don't think this actually makes sense.
I don't think this proposal makes sense either, and yeah I didn't notice it for the same reason as @decathorpe.
-1
Metadata Update from @ngompa: - Issue tagged with: meeting
I very much dislike the way this Change is described. "This seems incompatible with the ostree model" sounds like the Change owner isn't sure. But people proposing changes really should do the work to figure out if the Change they are proposing make sense. They need to provide a consistent rationale and at least convince themselves.
Also, Changes need to be described as if they were done. Then, the text will correctly describe the state after release. "This proposal suggests" should not be used.
That said, I think the proposed change is actually OK. Anything derived solely from other stuff in /usr can just go into /usr. We did such a change recently with https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr, and previously with https://fedoraproject.org/wiki/Changes/FontconfigCacheDirChange. In all three cases the rationale is similar. Those files are not part of the package payload, but are determined by the package state. If we roll back the package changes, we want to roll back those additional files too. Those files are generated during the rpm transaction, which means that at the time /usr must be writeable, so there is no problem with saving the modifications.
/usr
@walters, wdyt?
In all three cases the rationale is similar.
Yep exactly!
I don't think this actually makes sense. I don't think this proposal makes sense either,
Can either of you provide any more rationale?
My apologies for the wording in the change.
This change is derived from a request from the image-mode team, which uses the /var directory for a specific purpose and thus can't be used for the man-db cache [1].
/var
I've already tried to implement it [2] and it all worked without any issues.
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
Looks like in this change, they've created a symlink to help with compatibility. Do you believe it should be done in man-db as well? It may actually help to resolve the fear about third-party apps, depending on this path.
[1] https://bootc-dev.github.io/bootc/filesystem.html#var [2] https://src.fedoraproject.org/rpms/man-db/pull-request/21
Note that a lot of the partitioning/filesystem layout design directions are not specific to ostree/bootc. See for example https://github.com/openSUSE/transactional-update?tab=readme-ov-file#caveats which says
Data in /var must not be available during the update, as changes in there would necessarily modify the state of the currently running system.
Everyone working in this space has converged to the same high level approaches (implementation details below vary).
Please refrain from discussing details of the proposal here, that's that the discussion thread is for. (I am still waiting for a response to my questions there.)
Metadata Update from @fale: - Issue untagged with: meeting
Hi, can you please reevaluate since the questions were answered, also in the discussion thread
+1
This was will be discussed in the meeting next week.
Metadata Update from @zbyszek: - Issue tagged with: meeting
But the Change Checkpoint: 100% Code Complete Deadline is Tue 2025-08-26, isn't that a problem?
Change Checkpoint: 100% Code Complete Deadline
Tue 2025-08-26
Well ... pedantically, yes, but practically, not really.
And what is the resolution now? Can I move forward?
Looks like we forgot to update the ticket(s) after yesterday's meeting:
Metadata Update from @ngompa: - Issue untagged with: meeting
Metadata Update from @ngompa: - Issue tagged with: pending announcement
Metadata Update from @ngompa: - Issue untagged with: pending announcement
Metadata Update from @ngompa: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)