On Sun, Aug 11, 2013 at 2:31 AM, Pacho Ramos <pa...@gentoo.org> wrote: > El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió: >> 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 >> > > Maybe the second point could be solved having some kind of "minimal" USE > flag for systemd building it with only the minimum set for running udev > without adding so many dependencies. Regarding the first issue, I have > also seen that will be nearly impossible to reach a consensus because we > are currently in a strange intermediate situation: we don't have a setup > ready to run without /usr but neither /usr merge work :| > > Then, I guess will have to live with this two alternatives more time :/, > but people running Gnome will need to keep /usr mounted and, then, they > won't suffer the first problem of place installation.
systemd doesn't support separated /usr without an initramfs, so there is no problem now that GNOME requires it. > Also, the extra > dependencies won't be so "extra" for gnome users, letting them to move > to systemd ebuild easily And there is that. Although the only hard (runtime) dependencies of systemd-206-r3 are: sys-apps/dbus sys-apps/util-linux sys-libs/libcap sys-apps/baselayout sys-apps/hwids Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México