[gentoo-user] Mutually exclusive ebuilds?

[gentoo-user] Mutually exclusive ebuilds?

[Grant]

I'm getting this and I'm wondering if it means I can't have miro and
wicd installed simultaneously:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-python/pyrex:0
  ('installed', '/', 'dev-python/pyrex-0.9.8.5', 'nomerge') pulled in by
    >=dev-python/pyrex-0.9.6.4 required by ('installed', '/',
'media-tv/miro-2.0.1', 'nomerge')
    (and 1 more)
  ('ebuild', '/', 'dev-python/pyrex-0.9.4.1', 'merge') pulled in by
    >=dev-python/pyrex-0.9.3-r2 required by ('installed', '/',
'dev-python/dbus-python-0.82.4', 'nomerge')
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.

# equery depends dbus-python
[ Searching for packages depending on dbus-python... ]
media-tv/miro-2.0.1 (dev-python/dbus-python)
net-misc/wicd-1.5.9-r1 (dev-python/dbus-python)

- Grant

[gentoo-user] Re: Mutually exclusive ebuilds?

[James]

Grant <emailgrant <at> gmail.com> writes:


> # equery depends dbus-python
> [ Searching for packages depending on dbus-python... ]
> media-tv/miro-2.0.1 (dev-python/dbus-python)
> net-misc/wicd-1.5.9-r1 (dev-python/dbus-python)


Grant,

How are you getting miro?
#rd party ebuild?

My /usr/portage/media-tv directory does not contain miro?

http://bugs.gentoo.org/show_bug.cgi?id=1315


curiously,
James

Re: [gentoo-user] Re: Mutually exclusive ebuilds?

[Grant]

>> # equery depends dbus-python
>> [ Searching for packages depending on dbus-python... ]
>> media-tv/miro-2.0.1 (dev-python/dbus-python)
>> net-misc/wicd-1.5.9-r1 (dev-python/dbus-python)
>
>
> Grant,
>
> How are you getting miro?
> #rd party ebuild?
>
> My /usr/portage/media-tv directory does not contain miro?
>
> http://bugs.gentoo.org/show_bug.cgi?id=1315
>
>
> curiously,
> James

There are good ebuilds here:

http://bugs.gentoo.org/show_bug.cgi?id=131527

- Grant

Re: [gentoo-user] Mutually exclusive ebuilds?

[Arttu V.]

On 2/21/09, Grant <emailgrant@gmail.com> wrote:
> I'm getting this and I'm wondering if it means I can't have miro and
> wicd installed simultaneously:
>
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
> dev-python/pyrex:0
>   ('installed', '/', 'dev-python/pyrex-0.9.8.5', 'nomerge') pulled in by
>     >=dev-python/pyrex-0.9.6.4 required by ('installed', '/',
> 'media-tv/miro-2.0.1', 'nomerge')
>     (and 1 more)
>   ('ebuild', '/', 'dev-python/pyrex-0.9.4.1', 'merge') pulled in by
>     >=dev-python/pyrex-0.9.3-r2 required by ('installed', '/',
> 'dev-python/dbus-python-0.82.4', 'nomerge')
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously.

The gurus remain silent, but I have a theory. A bug in portage. I've
had several similar-looking nonsensical blockers lately -- after
portage learned to solve some blockers automatically, actually.

I think at the same time portage lost its ability to figure out that
if you have an unstable version package-3.4.5 installed and you're
installing another package, which requires, e.g., >=package-1.2.3 and
the stable for that slot (and oldest available in portage tree) is
between the two, e.g., package-2.3.4 then portage seems to produce
these kinds of situations: wants to downgrade to 2.3.4, but
simultaneously to keep the 3.4.5 in the same slot.

I just had dev-libs/glib do the same two-three days ago. I have the
unstable 2.18.4 installed, package comes along that requires
>=glib-2.14 and the latest stable in portage is 2.16.4 or something
for that slot. Boom, similar nonsensical blocker.

I've been solving them by unmerging the "blocker" and retrying the
emerge. Portage has invariably proceeded without a slightest hint of
blockers -- and re-emerged the unstable package version it just
complained was causing a blocker. So, there, I think it could very
well be a bug in portage. Maybe it has a bug report?

-- 
Arttu V.

Re: [gentoo-user] Mutually exclusive ebuilds?

[Grant]

>> I'm getting this and I'm wondering if it means I can't have miro and
>> wicd installed simultaneously:
>>
>> !!! Multiple package instances within a single package slot have been pulled
>> !!! into the dependency graph, resulting in a slot conflict:
>> dev-python/pyrex:0
>>   ('installed', '/', 'dev-python/pyrex-0.9.8.5', 'nomerge') pulled in by
>>     >=dev-python/pyrex-0.9.6.4 required by ('installed', '/',
>> 'media-tv/miro-2.0.1', 'nomerge')
>>     (and 1 more)
>>   ('ebuild', '/', 'dev-python/pyrex-0.9.4.1', 'merge') pulled in by
>>     >=dev-python/pyrex-0.9.3-r2 required by ('installed', '/',
>> 'dev-python/dbus-python-0.82.4', 'nomerge')
>> It may be possible to solve this problem by using package.mask to
>> prevent one of those packages from being selected. However, it is also
>> possible that conflicting dependencies exist such that they are
>> impossible to satisfy simultaneously.
>
> The gurus remain silent, but I have a theory. A bug in portage. I've
> had several similar-looking nonsensical blockers lately -- after
> portage learned to solve some blockers automatically, actually.
>
> I think at the same time portage lost its ability to figure out that
> if you have an unstable version package-3.4.5 installed and you're
> installing another package, which requires, e.g., >=package-1.2.3 and
> the stable for that slot (and oldest available in portage tree) is
> between the two, e.g., package-2.3.4 then portage seems to produce
> these kinds of situations: wants to downgrade to 2.3.4, but
> simultaneously to keep the 3.4.5 in the same slot.
>
> I just had dev-libs/glib do the same two-three days ago. I have the
> unstable 2.18.4 installed, package comes along that requires
>>=glib-2.14 and the latest stable in portage is 2.16.4 or something
> for that slot. Boom, similar nonsensical blocker.
>
> I've been solving them by unmerging the "blocker" and retrying the
> emerge. Portage has invariably proceeded without a slightest hint of
> blockers -- and re-emerged the unstable package version it just
> complained was causing a blocker. So, there, I think it could very
> well be a bug in portage. Maybe it has a bug report?
>
> --
> Arttu V.

Thanks for your message.  You gave me an idea and I added pyrex to
package.keywords and now there is no blocker.  Now I can emerge world,
but the weird thing is pyrex isn't even in the list of packages to
emerge.

- Grant

Re: [gentoo-user] Mutually exclusive ebuilds?

[Grant]

>>> I'm getting this and I'm wondering if it means I can't have miro and
>>> wicd installed simultaneously:
>>>
>>> !!! Multiple package instances within a single package slot have been pulled
>>> !!! into the dependency graph, resulting in a slot conflict:
>>> dev-python/pyrex:0
>>>   ('installed', '/', 'dev-python/pyrex-0.9.8.5', 'nomerge') pulled in by
>>>     >=dev-python/pyrex-0.9.6.4 required by ('installed', '/',
>>> 'media-tv/miro-2.0.1', 'nomerge')
>>>     (and 1 more)
>>>   ('ebuild', '/', 'dev-python/pyrex-0.9.4.1', 'merge') pulled in by
>>>     >=dev-python/pyrex-0.9.3-r2 required by ('installed', '/',
>>> 'dev-python/dbus-python-0.82.4', 'nomerge')
>>> It may be possible to solve this problem by using package.mask to
>>> prevent one of those packages from being selected. However, it is also
>>> possible that conflicting dependencies exist such that they are
>>> impossible to satisfy simultaneously.
>>
>> The gurus remain silent, but I have a theory. A bug in portage. I've
>> had several similar-looking nonsensical blockers lately -- after
>> portage learned to solve some blockers automatically, actually.
>>
>> I think at the same time portage lost its ability to figure out that
>> if you have an unstable version package-3.4.5 installed and you're
>> installing another package, which requires, e.g., >=package-1.2.3 and
>> the stable for that slot (and oldest available in portage tree) is
>> between the two, e.g., package-2.3.4 then portage seems to produce
>> these kinds of situations: wants to downgrade to 2.3.4, but
>> simultaneously to keep the 3.4.5 in the same slot.
>>
>> I just had dev-libs/glib do the same two-three days ago. I have the
>> unstable 2.18.4 installed, package comes along that requires
>>>=glib-2.14 and the latest stable in portage is 2.16.4 or something
>> for that slot. Boom, similar nonsensical blocker.
>>
>> I've been solving them by unmerging the "blocker" and retrying the
>> emerge. Portage has invariably proceeded without a slightest hint of
>> blockers -- and re-emerged the unstable package version it just
>> complained was causing a blocker. So, there, I think it could very
>> well be a bug in portage. Maybe it has a bug report?
>>
>> --
>> Arttu V.
>
> Thanks for your message.  You gave me an idea and I added pyrex to
> package.keywords and now there is no blocker.  Now I can emerge world,
> but the weird thing is pyrex isn't even in the list of packages to
> emerge.
>
> - Grant

Looks like the ~amd64 version of pyrex was already installed so that
must have confused things.

- Grant

[gentoo-user] Re: Mutually exclusive ebuilds?

[James]

Grant <emailgrant <at> gmail.com> writes:


> There are good ebuilds here:
> http://bugs.gentoo.org/show_bug.cgi?id=131527

thx grant,

I'll just wait till it goes testing, then try
it.

I've got enough to hax @ these days.....





James

Re: [gentoo-user] Re: Mutually exclusive ebuilds?

[Grant]

>> There are good ebuilds here:
>> http://bugs.gentoo.org/show_bug.cgi?id=131527
>
> thx grant,
>
> I'll just wait till it goes testing, then try
> it.

Don't hold your breath. :)  1.2.8 was working perfectly for a long
time before 2.0 was released and there was never even a hint of
portage folks considering it in the bug.  It's a GREAT app and 2.0 is
a huge step up.

- Grant

>
> I've got enough to hax @ these days.....
>
>
>
>
>
> James