[gentoo-user] How to diagnose version conflicts?

[gentoo-user] How to diagnose version conflicts?

[Grant Edwards]

It seems that every time a new Python version is unmasks, it breaks
something on one or another of my machines.

This time it's a python-exec version conflict that prevents emerge
-u. FAICT, Python 3.10 requires python-exec 2.4.8, and some other
package requires 2.4.6.

I've fixed things temporarily with:

package.use:

   */* PYTHON_TARGETS: -python3_10
   */* PYTHON_SINGLE_TARGET -python3_10

package.mask:

   >=dev-lang/python-3.10

Now, at least I can continue to update the machine.

When I get the spare time to try to get Python 3.10 working, what is
the easiest way to figure out which package is causing the problem by
requring the older version of python-exec?

I've tried adding a 't' to the emerge flags, but that doesn't seem to
show anything useful.

Is there any documentation on how to determine the cause of a package
version conflict?

Here's what emerge says:

  (dev-lang/python-exec-conf-2.4.6:2/2::gentoo, ebuild scheduled for merge) pulled in by
      dev-lang/python-exec-conf required by (dev-lang/python-exec-2.4.8:2/2::gentoo, ebuild scheduled for merge) USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_10) (python3_8) (python3_9)"


python-exec-2.4.8 requires python-exec-conf which requires python-exec 2.4.6?

Re: [gentoo-user] How to diagnose version conflicts?

[Jack]

On 2022.01.11 19:11, Grant Edwards wrote:
> 
> It seems that every time a new Python version is unmasks, it breaks
> something on one or another of my machines.
> 
> This time it's a python-exec version conflict that prevents emerge
> -u. FAICT, Python 3.10 requires python-exec 2.4.8, and some other
> package requires 2.4.6.
> 
> I've fixed things temporarily with:
> 
> package.use:
> 
>    */* PYTHON_TARGETS: -python3_10
>    */* PYTHON_SINGLE_TARGET -python3_10
> 
> package.mask:
> 
>    >=dev-lang/python-3.10
> 
> Now, at least I can continue to update the machine.
> 
> When I get the spare time to try to get Python 3.10 working, what is
> the easiest way to figure out which package is causing the problem by
> requring the older version of python-exec?
> 
> I've tried adding a 't' to the emerge flags, but that doesn't seem to
> show anything useful.
> 
> Is there any documentation on how to determine the cause of a package
> version conflict?
> 
> Here's what emerge says:
> 
>   (dev-lang/python-exec-conf-2.4.6:2/2::gentoo, ebuild scheduled for  
> merge) pulled in by
>       dev-lang/python-exec-conf required by  
> (dev-lang/python-exec-2.4.8:2/2::gentoo, ebuild scheduled for merge)  
> USE="(native-symlinks) -test" ABI_X86="(64)" PYTHON_TARGETS="(pypy3)  
> (python3_10) (python3_8) (python3_9)"
> 
> 
> python-exec-2.4.8 requires python-exec-conf which requires  
> python-exec 2.4.6?
I was going to wonder if you are caught in the middle of an upgrade  
that's only partly reached the mirrors.  Given that (as I see it,  
having last done a sync a few hours ago) that there is ONLY one version  
each in the tree for python-exec-2.4.8 and python-exec-conf-2.4.6.  My  
response would just be wait an hour and re-sync.

However, looking at the ebuilds:
python-exe requires python-exec-conf (no version specified)
python-exec-conf-2.4.6 requires "!<dev-lang/python-exec-2.4.6-r4" which  
should allow 2.4.8.

I have both python 3.9.9-r1 and 3.10.0_p1-r1 installed (plus  
2.7.18_p13) so there doesn't seem to be any conflict there.  What does  
"equery d python-exec" tell you?

[gentoo-user] Re: How to diagnose version conflicts?

[Grant Edwards]

On 2022-01-12, Jack <ostroffjh@users.sourceforge.net> wrote:

>> python-exec-2.4.8 requires python-exec-conf which requires  
>> python-exec 2.4.6?
>
> I was going to wonder if you are caught in the middle of an upgrade  
> that's only partly reached the mirrors.  Given that (as I see it,  
> having last done a sync a few hours ago) that there is ONLY one version  
> each in the tree for python-exec-2.4.8 and python-exec-conf-2.4.6.

Yep, same here.

> However, looking at the ebuilds:
> python-exe requires python-exec-conf (no version specified)
> python-exec-conf-2.4.6 requires "!<dev-lang/python-exec-2.4.6-r4" which  
> should allow 2.4.8.
>
> I have both python 3.9.9-r1 and 3.10.0_p1-r1 installed (plus  
> 2.7.18_p13) so there doesn't seem to be any conflict there.  What does  
> "equery d python-exec" tell you?

After poking around a bit, I realized that the only machine that was
having this problem was also the only one that had python2.7
installed. Python 2.7 was required by ipkg-utils (for which the ebuild
seems to have long since vanished). The only thing I ever use from
ipkg-utils is the ipkg-build bash script. I copied that script to
~/bin/ and unmerged ipkg-utils.

emerge --depclean then removed python2.7, and then emerge -auvND
happily upgraded python-exec to 2.4.8.

Still not sure what command one uses to determine what package is
preventing some other package from being upgraded...

--
Grant

Re: [gentoo-user] Re: How to diagnose version conflicts?

[Arve Barsnes]

On Wed, 12 Jan 2022 at 01:44, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> Still not sure what command one uses to determine what package is
> preventing some other package from being upgraded...

It should all be in the emerge output, although it's quite hard to read.

If you want help interpreting it you could post the complete conflict
output, but what you've posted in your initial message is just the bit
that says that python-exec-2.4.8 requires python-exec-conf-2.4.6.
That's not a conflict, that's just one of the packages having one
dependency. To have a conflict, a different package would need to
require a different version.

Most of the times this particular kind of conflict is with an older
package that requires older PYTHON_TARGETS than can be provided, and I
expect something that got depcleaned with ipkg-utils, or ipkg-utils
directly, required python-exec or python-exec-conf with
PYTHON_TARGETS="python3_7". Note that dev-lang/python itself is not
the source of any of these problems, I still have python 2.7 and 3.10
installed (along with 3.9 which is the default version on this machine
now).

Regards,
Arve

[gentoo-user] Re: How to diagnose version conflicts?

[Grant Edwards]

On 2022-01-12, Arve Barsnes <arve.barsnes@gmail.com> wrote:
> On Wed, 12 Jan 2022 at 01:44, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>> Still not sure what command one uses to determine what package is
>> preventing some other package from being upgraded...
>
> It should all be in the emerge output, although it's quite hard to read.
>
> If you want help interpreting it you could post the complete conflict
> output, but what you've posted in your initial message is just the bit
> that says that python-exec-2.4.8 requires python-exec-conf-2.4.6.
> That's not a conflict, that's just one of the packages having one
> dependency. To have a conflict, a different package would need to
> require a different version.

Right. And how to determine which package requires the older version
is the question. Since I can't reinstall ipkg-utils, I don't have any
way to recreate the conflict.

> Most of the times this particular kind of conflict is with an older
> package that requires older PYTHON_TARGETS than can be provided, and I
> expect something that got depcleaned with ipkg-utils, or ipkg-utils
> directly, required python-exec or python-exec-conf with
> PYTHON_TARGETS="python3_7". Note that dev-lang/python itself is not
> the source of any of these problems, I still have python 2.7 and 3.10
> installed (along with 3.9 which is the default version on this machine
> now).

Then it must have been ipkg-utils itself that required the older
python_exec, but there was no ebuild present for it. I know that
ipkg-utils was not mentioned at all in the emerge output.

After unmerging ipkg-utils and python2.7 the conflict was gone.

Next time I'll keep a copy of the entire emerge output.

--
Grant

Re: [gentoo-user] Re: How to diagnose version conflicts?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Wed, 12 Jan 2022 14:53:06 -0000 (UTC), Grant Edwards wrote:

> Then it must have been ipkg-utils itself that required the older
> python_exec, but there was no ebuild present for it.

If it was installed through portage, there would have been an ebuild for
it, in /var/db/pkg. That's what portage was referencing when if made the
dependency calculations.


-- 
Neil Bothwick

"Daddy, what does formatting drive 'C' mean?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: How to diagnose version conflicts?

[Grant Edwards]

On 2022-01-12, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 12 Jan 2022 14:53:06 -0000 (UTC), Grant Edwards wrote:
>
>> Then it must have been ipkg-utils itself that required the older
>> python_exec, but there was no ebuild present for it.
>
> If it was installed through portage, there would have been an ebuild
> for it, in /var/db/pkg.

Yes, correct past tense. There was at some point in the past when
ipkg-utils was installed.

> That's what portage was referencing when if made the dependency
> calculations.

There was no ipkg ebuild. There had been in the past, but it was
removed during an emerge --sync a while back. Last rites on 1 Aug
2020, removal 30 days later: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg90135.html

My conclusion was that dependency info for currently installed
packages is also stored somewhere else, since emerge still knew that
python-2.7 was required for ipkg-utils.

--
Grant

Re: [gentoo-user] Re: How to diagnose version conflicts?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Wed, 12 Jan 2022 16:25:29 -0000 (UTC), Grant Edwards wrote:

> > If it was installed through portage, there would have been an ebuild
> > for it, in /var/db/pkg.  
> 
> Yes, correct past tense. There was at some point in the past when
> ipkg-utils was installed.
> 
> > That's what portage was referencing when if made the dependency
> > calculations.  
> 
> There was no ipkg ebuild. There had been in the past, but it was
> removed during an emerge --sync a while back. Last rites on 1 Aug
> 2020, removal 30 days later:
> https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg90135.html

The ebuild would still have been on /var/db/pkg as long as it was
installed.

> My conclusion was that dependency info for currently installed
> packages is also stored somewhere else, since emerge still knew that
> python-2.7 was required for ipkg-utils.

Yes, in /var/db/pkg. That contains all the ebuild and data for installed
packages, independently of what is currently in the portage tree.


-- 
Neil Bothwick

I'm Pink, Therefore I'm Spam

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: How to diagnose version conflicts?

[Grant Edwards]

On 2022-01-12, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 12 Jan 2022 16:25:29 -0000 (UTC), Grant Edwards wrote:
>
>> > If it was installed through portage, there would have been an ebuild
>> > for it, in /var/db/pkg.  
>> 
>> Yes, correct past tense. There was at some point in the past when
>> ipkg-utils was installed.
>> 
>> > That's what portage was referencing when if made the dependency
>> > calculations.  
>> 
>> There was no ipkg ebuild. [...]
>
> The ebuild would still have been on /var/db/pkg as long as it was
> installed.

Doh!  Of course you're right.

I was getting /var/db/repos and /var/db/pkg mixed up. I had been
searching /var/db/repos not /var/db/pkg

--
Grant