[gentoo-user] Portage vs Qt

[gentoo-user] Portage vs Qt

[Philip Webb]

I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.

The emerge command responds with a list of "conflicts",
all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
The only way to get around this is to unmerge the existing pkgs via '-C',
then install the new versions.  That works, but it's brute force.

Portage sb able to resolve this kind of conflict for itself.
If not, then at least it should advise users intelligently
to do what I've just described.  It can happen with other sets of pkgs.

Yes, I did do 'backtrack==30'.

Before I send in a bug, does anyone else have useful comments ?

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Portage vs Qt

[John Covici]

On Wed, 14 Dec 2016 00:06:00 -0500,
Philip Webb wrote:
> 
> I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
> 
> The emerge command responds with a list of "conflicts",
> all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
> The only way to get around this is to unmerge the existing pkgs via '-C',
> then install the new versions.  That works, but it's brute force.
> 
> Portage sb able to resolve this kind of conflict for itself.
> If not, then at least it should advise users intelligently
> to do what I've just described.  It can happen with other sets of pkgs.
> 
> Yes, I did do 'backtrack==30'.
> 
> Before I send in a bug, does anyone else have useful comments ?

I wonder if a larger backtrack=120 or higher would fix your problem or
get portage to detect the blocks?  30 seems hardly enough these days.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: [gentoo-user] Portage vs Qt

[J. Roeleveld]

On Wednesday, December 14, 2016 12:06:00 AM Philip Webb wrote:
> I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
> 
> The emerge command responds with a list of "conflicts",
> all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
> The only way to get around this is to unmerge the existing pkgs via '-C',
> then install the new versions.  That works, but it's brute force.
> 
> Portage sb able to resolve this kind of conflict for itself.
> If not, then at least it should advise users intelligently
> to do what I've just described.  It can happen with other sets of pkgs.
> 
> Yes, I did do 'backtrack==30'.
> 
> Before I send in a bug, does anyone else have useful comments ?

I did exactly the same upgrade on 2 machines, along with an entire plasma 
upgrade, and didn't encounter this issue.

For comparison, this is what I generally use:

# emerge -vauDN --with-bdeps=y @world
# emerge -va --depclean

Do you only upgrade subsets? Or the full world?
I found that with libraries like qt, python and similar, only upgrading those 
makes it impossible for portage to properly handle the blockers.

--
Joost

Re: [gentoo-user] Portage vs Qt

[Dale]

John Covici wrote:
> On Wed, 14 Dec 2016 00:06:00 -0500,
> Philip Webb wrote:
>> I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
>>
>> The emerge command responds with a list of "conflicts",
>> all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
>> The only way to get around this is to unmerge the existing pkgs via '-C',
>> then install the new versions.  That works, but it's brute force.
>>
>> Portage sb able to resolve this kind of conflict for itself.
>> If not, then at least it should advise users intelligently
>> to do what I've just described.  It can happen with other sets of pkgs.
>>
>> Yes, I did do 'backtrack==30'.
>>
>> Before I send in a bug, does anyone else have useful comments ?
> I wonder if a larger backtrack=120 or higher would fix your problem or
> get portage to detect the blocks?  30 seems hardly enough these days.
>

I set mine to 100 at least a year ago.  As you say, 30 just didn't go
quite deep enough in some situations.  It takes emerge longer to resolve
it but it seems to resolve it better which is better than being fast but
not able to complete the job. 

Dale

:-)  :-) 

Re: [gentoo-user] Portage vs Qt

[Mick]

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

On Wednesday 14 Dec 2016 06:48:41 J. Roeleveld wrote:
> On Wednesday, December 14, 2016 12:06:00 AM Philip Webb wrote:
> > I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
> > 
> > The emerge command responds with a list of "conflicts",
> > all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
> > The only way to get around this is to unmerge the existing pkgs via '-C',
> > then install the new versions.  That works, but it's brute force.
> > 
> > Portage sb able to resolve this kind of conflict for itself.
> > If not, then at least it should advise users intelligently
> > to do what I've just described.  It can happen with other sets of pkgs.
> > 
> > Yes, I did do 'backtrack==30'.
> > 
> > Before I send in a bug, does anyone else have useful comments ?
> 
> I did exactly the same upgrade on 2 machines, along with an entire plasma
> upgrade, and didn't encounter this issue.
> 
> For comparison, this is what I generally use:
> 
> # emerge -vauDN --with-bdeps=y @world
> # emerge -va --depclean
> 
> Do you only upgrade subsets? Or the full world?
> I found that with libraries like qt, python and similar, only upgrading
> those makes it impossible for portage to properly handle the blockers.
> 
> --
> Joost

I came across a similar problem on 4 PCs.  From memory the problem was 
resolved when I manually unmerged dev-qt/qtcore and then updated world with 
backtrack=90.  I did not have to run --with-bdeps=y.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-user] Portage vs Qt

[J. Roeleveld]

On December 15, 2016 5:31:58 PM GMT+01:00, Mick <michaelkintzios@gmail.com> wrote:
>On Wednesday 14 Dec 2016 06:48:41 J. Roeleveld wrote:
>> On Wednesday, December 14, 2016 12:06:00 AM Philip Webb wrote:
>> > I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
>> > 
>> > The emerge command responds with a list of "conflicts",
>> > all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
>> > The only way to get around this is to unmerge the existing pkgs via
>'-C',
>> > then install the new versions.  That works, but it's brute force.
>> > 
>> > Portage sb able to resolve this kind of conflict for itself.
>> > If not, then at least it should advise users intelligently
>> > to do what I've just described.  It can happen with other sets of
>pkgs.
>> > 
>> > Yes, I did do 'backtrack==30'.
>> > 
>> > Before I send in a bug, does anyone else have useful comments ?
>> 
>> I did exactly the same upgrade on 2 machines, along with an entire
>plasma
>> upgrade, and didn't encounter this issue.
>> 
>> For comparison, this is what I generally use:
>> 
>> # emerge -vauDN --with-bdeps=y @world
>> # emerge -va --depclean
>> 
>> Do you only upgrade subsets? Or the full world?
>> I found that with libraries like qt, python and similar, only
>upgrading
>> those makes it impossible for portage to properly handle the
>blockers.
>> 
>> --
>> Joost
>
>I came across a similar problem on 4 PCs.  From memory the problem was 
>resolved when I manually unmerged dev-qt/qtcore and then updated world
>with 
>backtrack=90.  I did not have to run --with-bdeps=y.

The with bdeps option actually meant I didn't have to unmerge anything.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Re: Portage vs Qt

[Kai Krakow]

Am Wed, 14 Dec 2016 00:06:00 -0500
schrieb Philip Webb <purslow@ca.inter.net>:

> I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
> 
> The emerge command responds with a list of "conflicts",
> all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
> The only way to get around this is to unmerge the existing pkgs via
> '-C', then install the new versions.  That works, but it's brute
> force.
> 
> Portage sb able to resolve this kind of conflict for itself.
> If not, then at least it should advise users intelligently
> to do what I've just described.  It can happen with other sets of
> pkgs.
> 
> Yes, I did do 'backtrack==30'.
> 
> Before I send in a bug, does anyone else have useful comments ?

I constantly see the same conflict and haven't nailed it down exactly
right now. It seems to happen when one package requires a binary
compatibility to an older version of a depend but can also be built
against the newer version. Usually, emerge should trigger a rebuild
then. But this doesn't seem to work when both packages (the depend and
the depender) are updated at the same time. Portage then pulls in the
old and the new version of the same package at the same time, resulting
in a conflict.

Upgrading the depends with "-1a" first sometimes helps but usually I'll
also resolv it by unmerging the conflicting package first.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Portage vs Qt

[Mick]

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

On Saturday 17 Dec 2016 12:27:18 Kai Krakow wrote:
> Am Wed, 14 Dec 2016 00:06:00 -0500
> 
> schrieb Philip Webb <purslow@ca.inter.net>:
> > I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
> > 
> > The emerge command responds with a list of "conflicts",
> > all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
> > The only way to get around this is to unmerge the existing pkgs via
> > '-C', then install the new versions.  That works, but it's brute
> > force.
> > 
> > Portage sb able to resolve this kind of conflict for itself.
> > If not, then at least it should advise users intelligently
> > to do what I've just described.  It can happen with other sets of
> > pkgs.
> > 
> > Yes, I did do 'backtrack==30'.
> > 
> > Before I send in a bug, does anyone else have useful comments ?
> 
> I constantly see the same conflict and haven't nailed it down exactly
> right now. It seems to happen when one package requires a binary
> compatibility to an older version of a depend but can also be built
> against the newer version. Usually, emerge should trigger a rebuild
> then. But this doesn't seem to work when both packages (the depend and
> the depender) are updated at the same time. Portage then pulls in the
> old and the new version of the same package at the same time, resulting
> in a conflict.
> 
> Upgrading the depends with "-1a" first sometimes helps but usually I'll
> also resolv it by unmerging the conflicting package first.

Or, I usually end up unmerging the older version and emerge then picks up the 
latest stable version of the dependency.  I'm not saying this is the correct 
way to do it but either of these two methods get me out of the woods 
eventually.  
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-user] Re: Portage vs Qt

[Alan McKinnon]

On 17/12/2016 14:51, Mick wrote:
> On Saturday 17 Dec 2016 12:27:18 Kai Krakow wrote:
>> Am Wed, 14 Dec 2016 00:06:00 -0500
>>
>> schrieb Philip Webb <purslow@ca.inter.net>:
>>> I just updated Qt5 to 5.6.2 & ran into a familiar Portage problem.
>>>
>>> The emerge command responds with a list of "conflicts",
>>> all involving 5.6.1 vs 5.6.2 versions of the  c 15  pkgs.
>>> The only way to get around this is to unmerge the existing pkgs via
>>> '-C', then install the new versions.  That works, but it's brute
>>> force.
>>>
>>> Portage sb able to resolve this kind of conflict for itself.
>>> If not, then at least it should advise users intelligently
>>> to do what I've just described.  It can happen with other sets of
>>> pkgs.
>>>
>>> Yes, I did do 'backtrack==30'.
>>>
>>> Before I send in a bug, does anyone else have useful comments ?
>>
>> I constantly see the same conflict and haven't nailed it down exactly
>> right now. It seems to happen when one package requires a binary
>> compatibility to an older version of a depend but can also be built
>> against the newer version. Usually, emerge should trigger a rebuild
>> then. But this doesn't seem to work when both packages (the depend and
>> the depender) are updated at the same time. Portage then pulls in the
>> old and the new version of the same package at the same time, resulting
>> in a conflict.
>>
>> Upgrading the depends with "-1a" first sometimes helps but usually I'll
>> also resolv it by unmerging the conflicting package first.
> 
> Or, I usually end up unmerging the older version and emerge then picks up the 
> latest stable version of the dependency.  I'm not saying this is the correct 
> way to do it but either of these two methods get me out of the woods 
> eventually.  
> 


It is the "correct" way, but not because it has some stamp of approval :-)

It's correct because it's the easiest way out of a tricky problem that
is really hard to solve any other way.

It's a lot like doors - removing them is not exactly what they were
built for but if you need to get a 92cm couch through a 90cm door the
only way to get that extra 2cm is to take the door off it's hinges :-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com