Open cuantar opened 2 weeks ago
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.
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.
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.
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.)
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.
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.
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.
On
mark-testing
,x11-base/xorg-x11
is installed on my system in theworld
set, butemerge -c
wants to removex11-base/xorg-drivers
. That's clearly not the right thing to do, because it will also removex11-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.