Relocating Fedora's RPM database

Posted Jan 12, 2022 22:55 UTC (Wed) by mathstuf (subscriber, #69389)
Parent article: Relocating Fedora's RPM database

Other bits that feel like they'd be at home in `/state` include:

- TeX module databases (though I don't see what this is exactly in the guidelines)
- font databases (fc-cache)
- ldconfig caches
- gconfig schemas
- gobject-introspection bits (maybe?)

Relocating Fedora's RPM database

Posted Jan 13, 2022 0:20 UTC (Thu) by shalem (subscriber, #4062) [Link] (1 responses)

Note that everything you listed is stuff which you update when you update files under /usr. Most of it basically is indexes to making looking thing under /usr up faster, so regenerating this together with any changes to /usr and having them in sync with /usr really makes sense.

I'm not really involved in this whole discussion but to me /state feel like a solution which is looking for a problem to solve, rather then the other way around.

Relocating Fedora's RPM database

Posted Jan 13, 2022 6:32 UTC (Thu) by epa (subscriber, #39769) [Link]

Yep, there is a difference between metadata which is updated once when the installed software changes, and pure ‘cache’ which can be regenerated at any time.

Relocating Fedora's RPM database

Posted Jan 13, 2022 1:54 UTC (Thu) by ebassi (subscriber, #54855) [Link] (2 responses)

> - gobject-introspection bits (maybe?)

g-i is machine readable ABI description; it's the equivalent of a header file and the shared library. Definitely not "state", unless you consider libraries as state. You cannot delete the introspection data without breaking applications written in any dynamic language, for instance.

Relocating Fedora's RPM database

Posted Jan 13, 2022 2:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

I thought there was a central db of g-i bits. Am I confusing it with something else or was this previous behavior that isn't done anymore?

Relocating Fedora's RPM database

Posted Jan 13, 2022 9:52 UTC (Thu) by smcv (subscriber, #53363) [Link]

I think you're confusing it with something else.

The pattern where there's a compiled summary/cache/more-efficient-form for multiple files (like GSettings schemas glib-2.0/schemas/*.xml being summarized in gschemas.compiled) is useful if at least one of these is true:

* the files being summarized are in a format that is relatively costly to parse, compared with the number of programs that will want to parse it, so updating a summary during package management operations is cheaper than reading the source files from first principles every time (like schema XML)
* there are lots of files and many programs will want to load all of them, so reading the summary requires fewer syscalls and fewer disk seeks than reading the source files (like icons and fonts)
* the name of the correct file to open to get a particular "interface" is not immediately obvious unless you can look it up in the summary (like fonts, which have no obvious relationship between font name and filename)

None of those apply to GObject-Introspection: if a Python or JS program wants to use a GTK 3 UI, then it should already know (hard-coded in its source code) that it wants the Gtk typelib, API version 3.0, so it can load Gtk-3.0.typelib without needing to look it up in a summary. Typelibs are a binary format like a shared library, so the caller doesn't need to parse something like XML.