Bug 580444 – gnome2-utils.eclass: move to upstream way of running gdk-pixbuf-query-loaders

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Pacho Ramos 2016-04-18 15:24:32 UTC]

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

[Comment 1 Mart Raudsepp 2016-04-20 09:57:27 UTC]

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

[Comment 2 Gilles Dartiguelongue (RETIRED) 2016-09-08 21:48:49 UTC]

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.

[Comment 3 Pacho Ramos 2016-09-17 10:38:58 UTC]

Well, it seems that we have always run this in this way:
https://www.mail-archive.com/[e-mail]/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 :/

[Comment 4 Gilles Dartiguelongue (RETIRED) 2016-09-17 11:45:23 UTC]

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.

[Comment 5 Pacho Ramos 2016-09-17 11:54:11 UTC]

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)

[Comment 6 Gilles Dartiguelongue (RETIRED) 2016-09-17 12:10:15 UTC]

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) ?

[Comment 7 Pacho Ramos 2016-09-17 12:33:43 UTC]

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 :/)