Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Pacho Ramos <pacho@gentoo.org>]

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) :/
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)