| Summary: | gnome2-utils.eclass: move to upstream way of running gdk-pixbuf-query-loaders | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
| Component: | Eclasses | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | esigra |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 262490 | ||
To have the cache be owned by the package, not hang around as an unowned file in /usr, I believe. I think it was triggered by sabayon wishes too. Though I'm not sure why in an eclass when multiple packages probably shouldn't be owning that same cache file..? iirc, the tool is not locking the file and writing "line by line" which could result in an incomplete file between merges. Discussion about these details took place on gentoo-dev mailing list. Well, it seems that we have always run this in this way: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg60549.html But looking to: https://bugs.gentoo.org/show_bug.cgi?id=413529 https://bugs.gentoo.org/show_bug.cgi?id=413485 For this case it seems that we should really "die" when gdk-pixbuf-query-loaders --update-cache fails :/ Hum, the tickets seem pretty clear to me, the goal is to not replace the cache files if the tool failed. Dying is not acceptable as it would put a stop to the build and just leave you with a broken system while we can just go on with an outdated file. It does print an error message when that happens so I think current status is ok but maybe I am missing the whole point. Well, my point is that... if "gdk-pixbuf-query-loaders --update-cache" is failing and, still, it updated the cache file... maybe it's a bug in gdk-pixbuf-query-loaders :/ (if this is still happening with current versions) Sure, but current approach aims to solve 2 problems: 1. do not replace the file if the tool failed for one reason or another as it is better to have an outdated cache than a broken desktop (to various extents according to the tool) 2. replace the cache file as atomically as possible, some of the update tools are notorious for writing the file line by line which results race conditions where desktop might appear broken while updating when it actually isn't if you just wait for the update to finish. So I guess what your report is really about is that we should audit these tools to make sure they do it the right way (as some already do) ? Yes, because we are relying on "--update" for some tools but not others, then, I am unsure about the pathway to follow and if we are being safe enough in all the cases (or we will need to add this "complex" way for all the tools :/) |
I don't know why we are running this: gnome2_gdk_pixbuf_update() { has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}" local updater="${EROOT}/usr/bin/${CHOST}-gdk-pixbuf-query-loaders" if [[ ! -x ${updater} ]]; then updater="${EROOT}/usr/bin/gdk-pixbuf-query-loaders" fi if [[ ! -x ${updater} ]]; then debug-print "${updater} is not executable" return fi if [[ -z ${GNOME2_ECLASS_GDK_PIXBUF_LOADERS} ]]; then debug-print "gdk-pixbuf loader cache does not need an update" return fi ebegin "Updating gdk-pixbuf loader cache" local tmp_file=$(emktemp) ${updater} 1> "${tmp_file}" && chmod 0644 "${tmp_file}" && cp -f "${tmp_file}" "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" && rm "${tmp_file}" # don't replace this with mv, required for SELinux support eend $? } Instead of simply calling gdk-pixbuf-query-loaders --update-cache Any thoughts? Thanks