On 08/12/2017 15:22, Alexey Eschenko wrote:
> It can be the issue. But older version (2.0.4) which is currently
> installed works fine and has no conflicts.
>
> It's quite strange.
>
>
> On 12/08/2017 03:39 PM, Vadim A. Misbakh-Soloviov wrote:
>>> Is it really necessary to block one package when another installed?
>> Most of the time, the reason to make packages to block each other is
>> collisions (if they they contain files (like binaries or libraries)
>> with same
>> install paths).
>>
>> Although, I can't guarantee that it was the case here.
>>
>> I've noticed that Gnome Team makes some decisions, that doesn't looks
>> logical
>> for a few times already.
>>
>
It's not at all strange; it's quite ordinary actually.
Keeping in mind that I do not use these packages, or gnome, look at the
available blueman packages:
# eix net-wireless/blueman
* net-wireless/blueman
Available versions: (~)2.0.3 (~)2.0.4 [M](~)2.1_alpha1 **9999
{appindicator network nls policykit pulseaudio thunar
PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6"
PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
2.1 is still in an alpha state, and it is p.masked:
/var/portage/profiles/package.mask:
# Michał Górny <mgo...@gentoo.org> (26 Jan 2017)
# Pre-release, masked for testing. Major changes since 2.0.4,
# including dropped support for BlueZ 4.
It is not unreasonable to conclude that blueman-2.1 intends to add
features that conflict with gnome-bluetooth and they can't co-exist. As
Vadim said, file collisions are often the underlying cause.
You unmasked an alpha package, clearly tagged as "for testing". Nothing
add abut the result you got at all.
--
Alan McKinnon
alan.mckin...@gmail.com
