| 1 |
On R, 2017-12-08 at 19:39 +0700, Vadim A. Misbakh-Soloviov wrote: |
| 2 |
> > |
| 3 |
> > Is it really necessary to block one package when another installed? |
| 4 |
> |
| 5 |
> Most of the time, the reason to make packages to block each other is |
| 6 |
> collisions (if they they contain files (like binaries or libraries) |
| 7 |
> with same |
| 8 |
> install paths). |
| 9 |
> |
| 10 |
> Although, I can't guarantee that it was the case here. |
| 11 |
|
| 12 |
There was a blocker in blueman against gnome-bluetooth due to a file |
| 13 |
collision with gnome-bluetooth. This was removed with 2.0-r1, back in |
| 14 |
Oct 2015, as blueman upstream solved it. |
| 15 |
To me it looks like the change didn't make it to the live ebuild and |
| 16 |
then eventually sometime after 2.0.3 a bump was made via copying from |
| 17 |
9999, not the latest version, thus reinstating the blocker, possibly by |
| 18 |
accident. Or maybe on purpose, but I don't see an explanation for it in |
| 19 |
logs. |
| 20 |
Try to remove the blocker in blueman, see if files collide or not, and |
| 21 |
if not file a bug against blueman, possibly with info that it might |
| 22 |
have been accidental reintroduction due to..., etc. |
| 23 |
|
| 24 |
> I've noticed that Gnome Team makes some decisions, that doesn't looks |
| 25 |
> logical |
| 26 |
> for a few times already. |
| 27 |
|
| 28 |
Something not looking logical for you doesn't mean there isn't sound |
| 29 |
logic. In this case, it's not us who have a blocker possibly wrongly |
| 30 |
reintroduced here. |
| 31 |
|
| 32 |
|
| 33 |
Best, |
| 34 |
Mart Raudsepp |
| 35 |
Gentoo GNOME team lead |
Archives