#3462 Change: Man-DB cache directory change
Closed: Rejected by ngompa. Opened by amoloney.

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.

@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].

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

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].

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

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?

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:

  • TOPIC: #3462 Change: Man-DB cache directory change (@sgallagh:fedora.im, 17:11:28)
    • AGREED: Proposal is rejected for F43 (+6, 0, -0) (@sgallagh:fedora.im, 17:16:35)
      (The proposal is not very clear and it is late to try to implement it in F43.
      Owners are welcome to clarify and resubmit for f44.)

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)

Metadata