Except that fact that I didn't unmasked it.
# fgrep -rni blueman /etc/portage
/etc/portage/package.use/blueman:1:#net-wireless/blueman
But I understand other possible reasons.
On 12/08/2017 07:37 PM, Alan McKinnon wrote:
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.
--
Kind regards,
Alexey Eschenko
https://skobk.in/
