Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 567474 - [Future EAPI] Default to "unset DISPLAY"
Summary: [Future EAPI] Default to "unset DISPLAY"
Status: RESOLVED DUPLICATE of bug 499288
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2015-12-03 16:00 UTC by Pacho Ramos
Modified: 2017-09-09 11:01 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2015-12-03 16:00:28 UTC
Currently we can see in the tree plenty of ebuilds needing to run "unset DISPLAY" manually to fix many different of issues (you can a few of them while grepping in the tree as comments in relevant ebuilds). Also, it's not the first time I see a test suite behaving differently depending on it finding a random DISPLAY and, then, for example, you seeing a window popping up suddenly while failing when running in console.

Is there any reason for keeping DISPLAY set to a random value while building stuff? From my point of view, we should ensure packages are built without DISPLAY and, if an ebuild need a display, it should rely on virtualx.eclass to get the X stuff handled on a predictable way

Thanks a lot
Comment 1 Ulrich Müller gentoo-dev 2015-12-04 06:59:17 UTC
This would most likely go into section 11.1 "Defined Variables".
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-09-08 18:13:49 UTC
I don't mind this but then, I don't feel like adding more special variables is a good way forward. Maybe we should focus on the whitelist/blacklist option suggested elsewhere and WONTFIX/DUPE this one instead?
Comment 3 Ulrich Müller gentoo-dev 2017-09-09 11:01:21 UTC
Indeed, this looks like a special case that the more general blacklist would handle.

*** This bug has been marked as a duplicate of bug 499288 ***