On 09/08/13 12:51, Pacho Ramos wrote:
El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
escribió:
Pacho Ramos schrieb:
If OpenBSD can do it, then Gentoo can do it, too. So would you accept ebuild
patches that make it possible to install Gnome 3.8 without systemd again?
Only make it possible, not turn it into a configuration which the Gnome team
supports.
We have discussed this some times in the team, the problem is that we
don't think we should provide "by default" a setup that is not working
properly: powermanagement, multiseat support and gdm service handling
I don't say that it should be the default.
Also, if that people reports problems, we would
close them as WONTFIX -> migrate to systemd
That's what I meant when I wrote not a configuration that Gnome team supports.
- You can ignore the warnings, news and suggestions and, even moving
from udev to systemd ebuild, keep booting with openRC and using systemd
as device manager
- You can put systemd in package.provides to even keep running udev
The good part about package.provided is that users definitely know that they
are running an unsupported configuration with it. The bad part is that
putting systemd in package.provided is a bit dangerous, as this can lead to
udev unmerge on depclean if you are not careful.
This makes me think what is the problem with people moving to systemd as
udev provider (even running openrc) :/
Because sys-apps/systemd is installed in wrong directory structure in /usr
I still carry systemd in my local overlay instead of using it from
Portage, just to put it in / as per upstream recommendation :-/
We have tried to reach consensus, but there is a disagreement that we
have left at "We agree that we don't agree."
Pushing that aside, there is also the heavy dependencies of
sys-apps/systemd in comparison to sys-fs/udev
1. The first solution (moving to systemd as udev provider) would be
"easy" and would behave as bad as openBSD does (having the unsupported
and mid working setup)
2. About the other one: probably somebody adding systemd to
package.provide *on purpose* will remember to know that he needs a
device manager (either udev or eudev) and don't let depclean remove
it :|
Other possible solution would be the following:
3. Add a "openrc-force" USE flag to offending packages. This USE flag
would be masked in all profiles, needing users to unmask it locally (the
packages would warn about it when enabling and so)
