| 1 |
On Jul 27, 2013 4:44 PM, "walt" <w41ter@×××××.com> wrote: |
| 2 |
> |
| 3 |
> First hint: it's a mess -- don't do it on a critical machine. |
| 4 |
> (My main machine is ~amd64 and that's why I'm doing it on virtual |
| 5 |
> ~amd64 machines first.) |
| 6 |
> |
| 7 |
> The new gnome-shell demands that systemd be installed, even if you |
| 8 |
> don't intend to use it. |
| 9 |
> |
| 10 |
> The latest systemd conflicts with udev because the udev project |
| 11 |
> has been rolled into systemd, which now provides all of the files |
| 12 |
> previously installed by udev. |
| 13 |
> |
| 14 |
> Therefore your machine will still boot without udev because systemd |
| 15 |
> installs all the udev files. You don't need to start or use systemd |
| 16 |
> if you don't want to, but the systemd package must be installed |
| 17 |
> *before* you reboot and after removing udev. |
| 18 |
> |
| 19 |
> Removal of udev has caused a few (temporary) problems with useflags, |
| 20 |
> because a few packages still depend directly on udev instead of the |
| 21 |
> newer (!systemd ? udev) which means accept either one but not both. |
| 22 |
> That will get fixed soon, I'm sure. |
| 23 |
> |
| 24 |
> The right way to upgrade gnome is probably to remove every gnome |
| 25 |
> package on the machine, which will avoid many of the conflicts I've |
| 26 |
> had to fight for the last two days -- but of course I did it the hard |
| 27 |
> way instead :) |
| 28 |
> |
| 29 |
> You can try emerge -au gnome-light early in the update, which is |
| 30 |
> simpler than emerging gnome in all its immensity, but that's no |
| 31 |
> guarantee of success -- I'm sure you'll still run into conflicts |
| 32 |
> between packages and useflags, but it might be a bit easier. |
| 33 |
> |
| 34 |
> When you see conflicting packages that won't install, I suggest |
| 35 |
> deleting both packages immediately -- let portage sort out the |
| 36 |
> conflicts. Just keep removing packages until portage finally |
| 37 |
> stops complaining. |
| 38 |
> |
| 39 |
> Beware of pambase, however. I finally took Canek's advice and |
| 40 |
> removed consolekit from the machine and unset the useflag for |
| 41 |
> all packages, including pambase and polkit. I'd suggest you |
| 42 |
> get pambase and polkit re-installed with the proper useflags |
| 43 |
> before you try to reboot. Dunno if that's mandatory, but I did |
| 44 |
> it that way and had no problems (yet). |
| 45 |
> |
| 46 |
> I've finished updating my virtual gentoo systemd machine now, |
| 47 |
> but I'm still fighting with the virtual openrc machine and I'm |
| 48 |
> not sure how it will turn out. More tomorrow :) |
| 49 |
|
| 50 |
I haven't upgraded yet to the last update (although I've been using GNOME |
| 51 |
3+systemd for years), but I do know this: the primary reason of GNOME's |
| 52 |
dependency on systemd is logind, and logind *CANNOT* run correctly if |
| 53 |
systemd is not the running init. |
| 54 |
|
| 55 |
So you not only need to install systemd: you need to use it as init. I |
| 56 |
don't even think logind can start if systemd is not running. |
| 57 |
|
| 58 |
And actually, the long term plan is for systemd --user to basically replace |
| 59 |
gnome-session-manager, so just installing systemd is not going to work at |
| 60 |
all in the future, even if it *may* seems to work now (which I'm pretty |
| 61 |
sure it doesn't). |
| 62 |
|
| 63 |
systemd provides some pretty complex functionality for logind (and |
| 64 |
therefore GNOME) while running; it's not just some libraries. |
| 65 |
|
| 66 |
Regards. |
Archives