why is wayland getting pulled in?

[OpiateSkittles]

hey everyone, i've got a fairly new install going and i'm a bit thrown off by this emerge. in /etc/portage/make.conf, i have -wayland in my use flags, but for some reason it's getting pulled in, and creating a conflict in the process. anyone have an idea why? here is the output:

Code: Select all

> emerge -uDUav @world

These are the packages that would be merged, in order:

Calculating dependencies        ... done!
[ebuild     U  ] acct-group/plugdev-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/messagebus-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/polkitd-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/lp-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/lpadmin-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild  N     ] acct-group/portage-0::gentoo  0 KiB
[ebuild     U  ] acct-group/input-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/kvm-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/render-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/sshd-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/utmp-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] dev-db/lmdb-0.9.27:0/0.9.27::gentoo [0.9.24:0/0.9.24::gentoo] USE="-static-libs" ABI_X86="(64) -32 (-x32)" 141 KiB
[ebuild     U  ] acct-group/man-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-group/locate-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-user/messagebus-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-user/polkitd-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild  N     ] acct-user/portage-0::gentoo  0 KiB
[ebuild     U  ] acct-user/sshd-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild     U  ] acct-user/man-1-r1::gentoo [1::gentoo] 0 KiB
[ebuild     UD ] dev-lang/tcl-8.6.9-r1:0/8.6::gentoo [8.6.10:0/8.6::gentoo] USE="threads -debug" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild     U  ] dev-db/sqlite-3.34.0:3::gentoo [3.33.0:3::gentoo] USE="icu readline -debug -doc -secure-delete -static-libs -tcl -test -tools" ABI_X86="(64) -32 (-x32)" 12328 KiB
[ebuild  N     ] dev-util/wayland-scanner-1.18.91::gentoo  ABI_X86="(64) -32 (-x32)" 443 KiB
[ebuild     U  ] dev-libs/wayland-1.18.91::gentoo [1.18.0::gentoo] USE="-doc" ABI_X86="(64) -32 (-x32)" 0 KiB
[blocks b      ] <dev-libs/wayland-1.18.91 ("<dev-libs/wayland-1.18.91" is blocking dev-util/wayland-scanner-1.18.91)
[ebuild     U  ] sys-apps/dbus-1.12.20-r1::gentoo [1.12.20::gentoo] USE="X elogind -debug -doc (-selinux) -static-libs -systemd -test -user-session" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild     U  ] media-libs/ilmbase-2.5.3:0/25::gentoo [2.5.2:0/25::gentoo] USE="-large-stack -static-libs -test" ABI_X86="(64) -32 (-x32)" 26890 KiB

Total: 25 packages (21 upgrades, 1 downgrade, 3 new), Size of downloads: 39801 KiB
Conflict: 1 block

anyone have any thoughts? i'm still a little new to gentoo, so please be patient. i'm not sure if the block is a big deal, since i don't use wayland anyway, but i'm confused about why it's getting pulled in at all.

now that i look at it, it appears i have wayland installed already, which i'm confused about as well. but, am i understanding right that, since wayland <1.18.91 is blocking wayland scanner 1.18.91, once wayland 1.18.91 the conflict will resolve itself?

[Moderator edit: added [code] tags to preserve output layout. -Hu]

[asturm]

There is no block (that isn't auto-resolved by portage).

To find out what package pulls in wayland:

Code: Select all

equery d wayland

[fedeliallalinea]

Or add --tree emerge option to see the tree dependencies.

[Hu]

here is the output:

Please use the [code] tag for machine output. It looks better when rendered. I have added the tag to your existing post, but it would be helpful to other readers if you do this on your own next time.

Code: Select all

[ebuild     U  ] dev-libs/wayland-1.18.91::gentoo [1.18.0::gentoo] USE="-doc" ABI_X86="(64) -32 (-x32)" 0 KiB
[blocks b      ] <dev-libs/wayland-1.18.91 ("<dev-libs/wayland-1.18.91" is blocking dev-util/wayland-scanner-1.18.91)

As asturm says, Portage resolved this block on its own. A block with a lowercase b is a soft-block, which Portage solved and is merely reporting because its solution may have influenced the output. A block with an uppercase B is a hard block, which Portage failed to solve, and which you must now resolve yourself.

In this case, Portage is telling you that you cannot have a new wayland-scanner while retaining an old wayland. The fix is that Portage will upgrade both.

If you ever wonder why you have a package installed, the simplest solution is to ask Portage: emerge --ask --verbose --depclean category/package will either offer to remove the package, or show an explanation of why it is needed. If you only want to see the explanation, and have no intention of actually removing it, you could use --pretend in place of --ask.

[mike155]

And, by the way, why have you switched to unstable/testing?

The handbook clearly recommends to stay on stable: https://wiki.gentoo.org/wiki/Handbook:A ... e/Branches

Stable

The ACCEPT_KEYWORDS variable defines what software branch to use on the system. It defaults to the stable software branch for the system's architecture, for instance x86.

It is recommended to stick with the stable branch. However, if stability is not that much important and/or the administrator wants to help out Gentoo by submitting bug reports to https://bugs.gentoo.org, then the testing branch can be used instead.

Testing

To use more recent software, users can consider using the testing branch instead. To have Portage use the testing branch, add a ~ in front of the architecture.

The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. Users using the testing branch might very well be the first to discover a bug in the package in which case they should file a bug report to let the developers know about it.

Beware though; using the testing branch might incur stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. Users that do not know how Gentoo works and how to solve problems, we recommend to stick with the stable and tested branch.

[pietinger]

OpiateSkittles,

you should not put "-wayland" in your make.conf. Also, you should not put "dri, dri3, drm, egl, gles, gles2 or gles3" in your make.conf. Let your desktop-profile do this job !

I use the plasma-profile and none of these use-flags are set in my make.conf (of my stable gentoo installation)

... and yes my "mesa" has the use-flags "dri3 egl gles2 wayland [...]" enabled
... and yes my "xorg-server" has "wayland" NOT enabled.

Dont forget the most settings are per package and NOT global !

[OpiateSkittles]

Thank you to all who responded. I guess I have testing enabled because, on my initial attempt at install, I followed a YouTube video because I was feeling a little overwhelmed. When setting up make.conf, he didn't say "~amd` was testing, per se, so that's what I did. I also used -Wayland because he disabled it globally and I figured, because I don't use Wayland, it would make sense for me to do the same. As for those other use flags you listed, I don't have them in my make.conf. Can you explain to me why I shouldn't have Wayland excluded in there? Just so I can build more of an understanding.

As for the code block, sorry about that, I was in a hurry this morning and half asleep when I made this post. I also apologize because I'm sure I could've answered my own question once I realized I already had Wayland installed for something else, but I'm happy I did because I'm here to learn and, had I not posted, I would not have learned that I shouldn't disable Wayland globally (eager to find out why) and realized I had the testing repo enabled.

Thank you all for your patience and advice.

[asturm]

Don't be sorry for asking questions.

I also used -Wayland because he disabled it globally and I figured, because I don't use Wayland, it would make sense for me to do the same. As for those other use flags you listed, I don't have them in my make.conf. Can you explain to me why I shouldn't have Wayland excluded in there?

It is of course anyone's prerogative to set "-wayland" globally, and you could do that only to find out that e.g. kde-plasma/kwin forces you to re-enable it on media-libs/mesa anyway. The plasma profile has made that default choice for you in order to make it a more pleasant experience installing packages with certain USE dependencies.

[OpiateSkittles]

Don't be sorry for asking questions.

It is of course anyone's prerogative to set "-wayland" globally, and you could do that only to find out that e.g. kde-plasma/kwin forces you to re-enable it on media-libs/mesa anyway. The plasma profile has made that default choice for you in order to make it a more pleasant experience installing packages with certain USE dependencies.

Yeah, I apologize too much. I always feel like a bother because of how I got treated in the Arch forums several years ago. I swear those people gave me PTSD.

As for Wayland, that's indeed why I had it installed. I had forgotten a per package flag I needed to set for Mesa. My thinking was that I don't want unnecessary wayland depends getting pulled in but, since kwin already pulled the main package in, I guess it's a moot point anyway.

Thanks again for the patience and help. This is a lovely community and is part of why I was so eager to join it.

[Hu]

Can you explain to me why I shouldn't have Wayland excluded in there? Just so I can build more of an understanding.

I think the nearby bold sentence was associated with this advice. For some flags, it is less trouble for you in the long run to find a Gentoo profile that is designed to do what you want, make that profile active, and then have a minimum of local overrides. This lets the maintainer of that profile enable/disable features that everyone on that profile will need changed, without you needing to follow along or discover those dependencies yourself. For example, maybe next year Plasma will require a new otherwise optional feature of Mesa to be enabled. The maintainer of the Plasma profile will set the profile so that anyone who follows its defaults gets a working environment automatically. Users who set a minimal profile will need to discover for themselves, probably through some sort of error message, that they did not enable the required feature. If you are on a profile that is not well suited to what you want (such as using a minimalist profile when you want to run a complex desktop environment), then you will spend more of your time enabling features that would have been configured correctly for you by the profile maintainer if you were on a profile suited to your needs.

As for the code block, sorry about that

This mistake is common enough that I have some helper macros defined so that I can add the block and the post script note about it. I wouldn't have said anything about it in a separate post, if I hadn't already had an on-topic reason to be posting here. (Specifically, I wanted to mention use of --pretend --depclean as a diagnostic mechanism.)

[OpiateSkittles]

For example, maybe next year Plasma will require a new otherwise optional feature of Mesa to be enabled. The maintainer of the Plasma profile will set the profile so that anyone who follows its defaults gets a working environment automatically. Users who set a minimal profile will need to discover for themselves, probably through some sort of error message, that they did not enable the required feature. If you are on a profile that is not well suited to what you want (such as using a minimalist profile when you want to run a complex desktop environment), then you will spend more of your time enabling features that would have been configured correctly for you by the profile maintainer if you were on a profile suited to your needs.

thank you for that detailed explanation. the example really made clear the base reasoning for setting a minimum of global use flags. part of why i ended up having so many global use flags initially (and i actually have trimmed them a bit, now) was that i intended to use XFCE as my DE, and i was worried that because it doesn't have a DE-specific profile, i might end up with some unnecessary or even disruptive fluff if i didn't specify what i didn't want. however, due to some annoyances in XFCE's recent development (that shouldn't really be an issue, it's just... well, i'll refrain from writing a page about why but, i have ocd. the real kind, not jokingly, and i can't handle some stuff with xfce right now, lbs). so anyway, i ended up switching to plasma and setting the profile after i'd already set up my make.conf. it's a whole thing, lol.

i'm starting to understand portage a lot better, and i'm actually a little embarrassed because i realize i essentially answered my own question right from the get-go in the initial post, but i posted it anyway because i was half-asleep and half freaked-out (anxiety issues too, lbvs). i don't regret it, though, because i benefited from the discussion. this is an exciting but occasionally frustrating and frightening new world, this distro, and i'm thankful for this forum and the general attitude i've experienced so far in the gentoo community.

anyway, sorry for the novel, and thanks again. not just you, but all who joined this discussion and all who answer my posts in the future.

-sincerely,
skitz

p.s: hi, me again, lol. for those wondering about my username (and i'm sure probably no one is but, like i said, anxiety issues are fun), i'm an ex-opiate addict have been in recovery for a year but, after 15 years with the same username across the entire web, i can't just up and switch lol. it's also why i can be a bit anxious, impulsive, and scatterbrained sometimes. it's all a work in progress. thanks in advance for your patience.

[noci2]

Mesa is also included on a headless system, used to emulate other systems.

and required to do so:

qemu needs virglrenderer, that needs libepoxy[egl] enabled which requires mesa.....

While all wayland are marked as experimental, and definitely not selected.
So there are use cases for not supporting wayland on the host i guess.
The build just fails.

Profile: default/linux/amd64/17.1

So for whom is the KDE development making things hard to do?