On 31/08/2015 16:03, cov...@ccs.covici.com wrote:
> Alan McKinnon <alan.mckin...@gmail.com> wrote:
>
>> 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
>>
>>
>>
>
> I think it has something to do with fail2ban -- the version of systemd
> in the tree after the 219 version is 224-r1 and 225 and now portage is
> saying
> WARNING: One or more updates/rebuilds have been skipped due to a
> dependency conflict:
> and one of those says
> (sys-apps/systemd-225:0/2::gentoo, ebuild scheduled for merge)
> conflicts with^M
>
> sys-apps/systemd[python(-),python_targets_python2_7(-),python_single_target_python2_7(+),python_targets_python3_4(-)]
> required by (net-analyzer/fail2ban-0.9.3:0/0::gentoo, installed)
> Does that make sense?
>
The words make sense, the meaning doesn't :-)
It looks like fail2ban wants systemd without python support, but the
true reason is still hidden. The fail2ban ebuild has this:
RDEPEND="
...
systemd? ( $(python_gen_cond_dep '|| (
dev-python/python-systemd[${PYTHON_USEDEP}]
sys-apps/systemd[python(-),${PYTHON_USEDEP}]
I'm thinking maybe you have a specific portage entry that's getting in
the way. What are your results for:
emerge --info
grep -r python /etc/portage
grep -r systemd /etc/portage
--
Alan McKinnon
alan.mckin...@gmail.com
