[core-gl-kit] `xorg-x11` probably should depend on `xorg-drivers`, but seems not to

[cuantar]

On mark-testing, x11-base/xorg-x11 is installed on my system in the world set, but emerge -c wants to remove x11-base/xorg-drivers. That's clearly not the right thing to do, because it will also remove x11-drivers/xf86-input-evdev and friends, rendering my Xserver inoperable... won't it? Did something change in how these packages are implemented?

I suspect it's a dependency issue, but haven't checked the ebuild so perhaps I'm wrong about the source of this problem.

[geaaru]

Well, i'm not sure that is a real issue that we want to fix. x11-base/xorg-drivers is a virtual package that inject multiples drivers based on use flags. But this doesn't mean that you really need evdev stuff. It's more something based on the world file of the users and the requested packages installed by the users. I'm sure that if you add x86-input-evdev package between the list of the packages that you want to install this will not happens anymore. Can you try this and check what are the use flags enabled in xorg-drivers?

Portage tries to resolve the reverse dependencies of the world packages and probably doesn't find a real dependency to this and doesn't find match. If the input_devices_evdev flag from your side is set, well, this seems more a Portage issue that could be resolved with the add of the package in the world list with less effort.

IMHO, i'm not sure that I want statically add all drivers by default. This is a PITA that doesn't match the real world. In the container/server world you can to have the needs of the X11 libraries but not the drivers. For example using the grafana-image-renderer plugin in a container needs xorg stuff because this plugin uses a headless chromium installation that just starts the browser in background and get the PNG and needs only main xorg-server libraries. But this doesn't means that you need evdev driver.

Btw, considering that in the near future we will split the branches between desktop and container/server this could be managed in different mode for Desktop and Server mode based on a specific profile mix-in. But I think that instead to call the virtual base as x11-base/xorg-drivers could be better to have a name like virtual/xorg-drivers in the near future that describe better what this package do and that is a virtual package. Just my cent.

[cuantar]

We have xorg-server that should be independent from the drivers, no? The xorg-x11 meta package is supposed to pull in everything to have a complete X.org distribution. I think we should fix it to keep the behavior consistent, and be using xorg-server for cases that need only the XServer deps. The USE flags for which drivers to include are set ~by ego~ in the profile, not manually. The xorg-drivers package facilitates the mapping between ego and portage.

... well, I looked carefully ~and found that I'm wrong about where is the ego involvement~. The input device USE flags are set somewhere in the profile, but not by mix-ins like I thought. I guess that it's probably part of the desktop flavor. The video flags are indeed set directly by mix-ins.

In my case, I definitely want to keep evdev and its friends installed, because they are vital. This machine is a laptop, not a server.

[cuantar]

So anyway, something isn't right, because the relevant USE flags are set already by the profile. The drivers package should be installed to pull in the correct driver packages, at least in the desktop profile. Are you suggesting that we need different ebuilds with different deps, so that only the desktop profile version of the xorg-x11 meta package depends on xorg-drivers at all?

My preferred solution would be to make the drivers package "empty" in the case of server profiles that don't set any driver USE flags. That way we aren't maintaining two versions of the same thing.

I like your idea of moving it to virtual/ to make clear what its purpose is.

[cuantar]

Here are the USE flags enabled in xorg-drivers. (Also, oops, that machine is a desktop. Doesn't matter much because the problem isn't unique to the laptop and it illustrates that the nvidia proprietary driver also is supposed to be pulled in this way, after being requested by ego and a mix-in.)

[cuantar]

Another reason I think we can consider this a bug worth fixing: emerge -c would break my system without any changes to /var/lib/portage/world. That's not great, because in Funtooland something like that would (ideally, and by effort) never happen.

[geaaru]

To confirm that is a Portage bug you need to see what are the USE flags enable in xorg-server. If xorg is not enable the behavior is correct. If it's present I think in any case this is not a bug and this is the same behavior that was before in Funtoo because the evdev package is injected as PDEPEND in xorg-drivers.

IIRC PDEPEND are packages that is good to have but not mandatory and normally PDEPEND is used to avoid dep cycles.

Indeed, the package xf86-input-evdev DEPENDs on xorg-server, if we change PDEPEND in RDEPEND we introduce dep cycles and a more bad issues of this. The use of PDEPEND is the "particular" way used by Portage to help the solver to order packages in the right way.

So, IMHO the solutions possible are:

a) just add the packages xf86-input-evdev in the list of the packages to install in order to have it in world list. I'm working to have a way to do this with anise-portage-converter tool too manually.

b) just to test... instead of using complex behavior it's possible define a set that could be used to install xorg base packages. I don't remember if the packages defined in the set are set as world package but could be a solution for this problem. The set probably is not injected automatically and add in the pipeline of the packages to install.

c) Drop the stupid injection of x11-base/xorg-drivers that has PDEPEND of the drivers/inputs and using a virtual/xorg-base that contains in RDEPEND xorg-server and xf86-* stuff based on the USE flags choice. The virtual/xorg-base must be the package injected by X mix-in.

[cuantar]

I'm thinking about what to do here. I've observed that on servers, the drivers also used to be pulled in but now are not. Now I lean toward adding xorg-drivers to the required packages in the desktop profiles, but only if X is installed. One easy way to do it: Add USE=drivers to xorg-x11, and then turn on that flag in package.use for the profile.