On 31/08/2015 13:49, cov...@ccs.covici.com wrote: >> A clue is in the ebuilds for systemd: >> > >> > sysv-utils? ( >> > !sys-apps/systemd-sysv-utils >> > !sys-apps/sysvinit ) >> > >> > That's a hard blocker, no way round it. It's in all the systemd ebuilds >> > for the current unstable versions. >> > >> > Do you have USE="sysv-utils" set for sysvinit? >> > >> > If so, to have both sysvinit and systemd, you will have to disable that >> > USE flag and see what comes next. > I put that use flag in there because I thought it would allow systemd to > generate a service from a script in /etc/init.d, but I will see what > happens when I remove that flag or maybe if there is another way to > accomplish that? > Well, that did it! It still is downgrading systemd, but that's not too > bad, thanks guys.
$ euses -sf sysv-utils sys-apps/systemd:sysv-utils - Install sysvinit compatibility symlinks and manpages for init, telinit, halt, poweroff, reboot, runlevel, and shutdown That description is quite vague, and could mean many things. I'm no expert on systemd, but I would imagine that it already has it's own scripts to deal with those listed functions. I wonder what the use of the flag is then? Perhaps an old compatibility layer than is not needed now? I can't see a reason why systemd is being downgraded; the previous output either lists just "sys-apps/systemd" or uses a ">=" operator. Nothing to say why 219_p112 is the highest usable version. Once the emerge finishes and portage has done what it wants, run these commands: emerge -pv systemd emerge -pv =systemd-225 (225 being latest in the tree). Then we can see better why portage is doing what it does -- Alan McKinnon alan.mckin...@gmail.com
