1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] profiles/base/make.defaults: add XDG_DATA_DIRS & XDG_CONFI

    From Pacho Ramos@21:1/5 to All on Wed Jul 17 21:00:01 2024
    Hello,

    This is a follow up from an older thread by leio in the mailing list: https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9

    The problem is that, at present time, we are getting more and more bugs
    coming from flatpak users that get build failures due to having those
    variables "polluted".

    Personally, I would opt for unsetting them too and properly set them to
    known values for packages needing it. But I am unsure if we could
    probably do a tinderbox run to find&fix packages needing them to be set
    :-/

    I copy and paste here the original mail from leio as he was explaining
    better the issue:
    ------------
    Hello,

    Unlike most other XDG base directories[1], we do not do anything with XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET. This is
    now causing some issues.

    Historically there was an issue[2] where a package added XDG_DATA_DIRS
    via env.d, which meant that if the base package (x11-misc/xdg-utils)
    wasn't yet installed, XDG_DATA_DIRS was set, but did not include the
    default paths, which broke some things as demonstrated there.

    Now there is an issue[3] where another package prepends other paths,
    which are not accessible when sandboxed and some tests are trying to
    access them. In my case, I'm now hitting this with flatpak, which
    prepends these paths via profile.d instead (and does have correct
    handling of the default dirs if XDG_DATA_DIRS was previously unset).

    This is a fundamental thing, so just unsetting it only in that package
    feels rather incomplete.
    I would think that the correct fix would be add XDG_DATA_DIRS to
    ENV_UNSET and also unsetting it in xdg_environment_reset (for the
    benefit of older EAPIs), but I fear that in some cases we specifically
    do need it to see what variables are in there. Perhaps prefix. If
    that's the case, per-ebuild unsetting could be problematic for those
    cases as well.

    Or is there some way to avoid such use cases of XDG_DATA_DIRS additions
    to not reach the portage environment in the first place?
    Thoughts?

    Mart

    1.
    https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
    2. https://bugs.gentoo.org/635040
    3. https://bugs.gentoo.org/701978
    ------------

    Thanks a lot for your thoughts

    -----BEGIN PGP SIGNATURE-----

    iQEzBAABCAAdFiEE808Ng0g83FMNupoifLEMIH/AfbwFAmaYE/0ACgkQfLEMIH/A fbxoDQf+IneXIWteH+WkyvhGUUMdy0SUBs6sqsi0NmTOejsunOfOBON1I3dgtQil RNRQp5TiLUvKq6SopcY25S91vtAst8OiUBDYkwtHy27OwHshRLUR2IAoqWOw8+oD 2/8HUxtRKWf7XaYt2O3xzN41HucyO09KcjAzGrqXaW05wVWcqkhjdsjJIPtLeltd cNrjiYhabovc0p1TD7Qgn0HzYz1sXW/K/QeUp4nKku2KfC4Wah9JDl2RYcmUGuD6 Q0MYaP3me8DA3bfwmJj0dafJ2HVUH+U1v/sfonqkPQ0oZBzWPpfwBShZUkIY1kdz WUPK1b9wPp2Mp44sCOORwyh4c6s85Q==
    =hQ0B
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Gilbert@21:1/5 to pacho@gentoo.org on Tue Aug 6 19:30:02 2024
    On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos <pacho@gentoo.org> wrote:

    Hello,

    This is a follow up from an older thread by leio in the mailing list: https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9

    The problem is that, at present time, we are getting more and more bugs coming from flatpak users that get build failures due to having those variables "polluted".

    Personally, I would opt for unsetting them too and properly set them to
    known values for packages needing it. But I am unsure if we could
    probably do a tinderbox run to find&fix packages needing them to be set
    :-/

    I'm not really familiar with the packages that require these
    variables. I agree with the idea in principle though.

    It seems like x11-libs/gtk+ is one example given by leio. How would we
    fix that one? Can the same strategy be applied to similar ebuilds?

    Another possible idea would be to source /etc/profile.env in a
    subshell and pick out the relevant XDG variables in
    xdg_environment_reset.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pacho Ramos@21:1/5 to All on Sat Nov 9 09:30:01 2024
    El mar, 06-08-2024 a las 13:27 -0400, Mike Gilbert escribió:
    On Wed, Jul 17, 2024 at 2:57 PM Pacho Ramos <pacho@gentoo.org> wrote:

    Hello,

    This is a follow up from an older thread by leio in the mailing
    list: https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9

    The problem is that, at present time, we are getting more and more
    bugs
    coming from flatpak users that get build failures due to having
    those
    variables "polluted".

    Personally, I would opt for unsetting them too and properly set
    them to
    known values for packages needing it. But I am unsure if we could
    probably do a tinderbox run to find&fix packages needing them to be
    set
    :-/

    I'm not really familiar with the packages that require these
    variables. I agree with the idea in principle though.

    It seems like x11-libs/gtk+ is one example given by leio. How would
    we
    fix that one? Can the same strategy be applied to similar ebuilds?

    Another possible idea would be to source /etc/profile.env in a
    subshell and pick out the relevant XDG variables in
    xdg_environment_reset.

    Hi!

    I have locally tried to append XDG_DATA_DIRS & XDG_CONFIG_DIRS to
    ENV_UNSET and x11-libs/gtk+-3.24.42-r1 looks to compile properly.

    I would then try to do a tinderbox run with they unset, if few packages
    are affected, we can set them to their expected values in relevant
    ebuilds. If there are many, maybe we can try to rely on
    xdg_environment_reset for more standardization.

    Regards

    -----BEGIN PGP SIGNATURE-----

    iQEzBAABCAAdFiEE808Ng0g83FMNupoifLEMIH/AfbwFAmcvG+kACgkQfLEMIH/A fbzt+Af/apJxhsDEUrszEgRCYn6sLTR7b8p/8yTndywjo1PszMzdUVYXs5D+r+7w B2J28j05gRTTv3YPZDt6JF5sKaOKcZ5V1FgLDk2KCKmGn1tWxqwrenteBX7JbjN5 0chw8LDtG46bc8Bs83pN3lYAQE4h/RxO5MbWmqlz4caM6+R5Fo882/g+WyMFyKXH ncVUtbv1KrEv5pvAwZ0BxhQoawYiHczpFBXAj+e5PH/zZ9qi1BH81GS9pR/askRP 566TKHF4gtf3DeD6F1c/36xSdO4vTpwxmUcAtGUrN7W2Z/CEUxrB5tXdv7i//liC V1pQVsGFBJxEwagbR1HywgqhYIvWRQ==
    =87MF
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)