On 11/08/13 10:31, Pacho Ramos 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. Also, the extra
dependencies won't be so "extra" for gnome users, letting them to move
to systemd ebuild easily
I'm propably opening a can of worms here but...
I've been considering packaging systemd in sys-fs/udev with
USE="systemd" and use of 'if' and 'else' plus creating virtual/systemd
for proper / installation and some other minor, but bad design choices
done in the systemd packaging
Previously, which isn't really true anymore because logind without
systemd is a dead end, there was also a reasoning of packaging logind,
and this type of packaging would have reduced the ebuild number to just
'udev', from 'udev, logind, systemd' since it's all from the same tarball
But now, the reason I haven't gone forward with it, is that I'm still
maintaining too much OpenRC related software that systemd has made
'deprecated' and I need OpenRC based system to be able to do that, and
using VM, dualboot or second machine for that is creating too much
overhead for my limited time
As in, I haven't made the final switch to systemd yet as a primary init
system on the main development machine which I consider a prereq for
packaging it, thus I'm keeping my hands off it and stick to the overlay
So with that said, I'm committed to keeping sys-fs/udev maintained and
the default for long as sys-apps/openrc is the default
If sys-fs/udev ever stops working without systemd, I'll maintain a
minimal patchset that reverts those changes, and if that becomes
unsustainable, we might consider forking it, but thistype of speculation
is far in the future (and the reason why sys-fs/eudev at this early
stage is stupid)
- Samuli
