[gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[Pacho Ramos]

Hello

I have encountered this behavior with acetoneiso ebuild:
http://bugs.gentoo.org/show_bug.cgi?id=197961

the current ebuild in sunrise will fix this dropping dep on
x11-libs/qt:4 but, anyway, I would want to confirm if the behavior noted
in:
http://bugs.gentoo.org/show_bug.cgi?id=197961#c19

is normal. I already know bug 161953 but, in my case, I have qt-gui
installed (emerge should now install also qt-webkit) and I don't have any
qt:4 version installed (only qt:3)

I would expect emerge to simply install qt-webkit as a "half" of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
DEPEND is already satisfied and none of x11-libs/qt:4 is

Thanks a lot :-)

Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pacho Ramos wrote:
> Hello
> 
> I have encountered this behavior with acetoneiso ebuild:
> http://bugs.gentoo.org/show_bug.cgi?id=197961
> 
> the current ebuild in sunrise will fix this dropping dep on
> x11-libs/qt:4 but, anyway, I would want to confirm if the behavior noted
> in:
> http://bugs.gentoo.org/show_bug.cgi?id=197961#c19
> 
> is normal. I already know bug 161953 but, in my case, I have qt-gui
> installed (emerge should now install also qt-webkit) and I don't have any
> qt:4 version installed (only qt:3)
> 
> I would expect emerge to simply install qt-webkit as a "half" of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
> DEPEND is already satisfied and none of x11-libs/qt:4 is
> 
> Thanks a lot :-)

|| ( ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) x11-libs/qt:4 )

It's a variation of bug 161953 [1]. For this particular variation,
at the moment I don't think there's a good way to distinguish that
the choice on the left is the better choice. However, if we
implement PROPERTIES=virtual [2] then we can use that to tag the
qt-4 ebuild as a virtual and then we should get better behavior due
to virtual lookahead mechanism that has been implemented for bug
141118 [3]. In the absence of PROPERTIES=virtual support, we'd have
to use a more complex approach such as the "avoid redundant
upgrades" algorithm suggested for bug 260225 [4].

[1] http://bugs.gentoo.org/show_bug.cgi?id=161953
[2]
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
[3] http://bugs.gentoo.org/show_bug.cgi?id=141118
[4] http://bugs.gentoo.org/show_bug.cgi?id=260225
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmsSSQACgkQ/ejvha5XGaN6VgCfcxRpXNv6dSr/wE7Mnes83Tz4
hOoAoJDSBSZ9UfCSRzYugo71vi4nYMcw
=/fIl
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[Pacho Ramos]

El lun, 02-03-2009 a las 13:01 -0800, Zac Medico escribió:
> || ( ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) x11-libs/qt:4 )
> 
> It's a variation of bug 161953 [1]. For this particular variation,
> at the moment I don't think there's a good way to distinguish that
> the choice on the left is the better choice. 

>From my point of view, I think that portage should do something like
calculating how much a dep is already in the system, for example, in
this case, I have 50% of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
already installed on my system while 0% of x11-libs/qt:4. Then,
( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) would be a better option
because, hopefully, a user that has already installed a portion of this
dep, will prefer to maintain it installed

But, this is only theoretical as I am not a programmer and I don't know
if this could be implemented

> However, if we
> implement PROPERTIES=virtual [2] then we can use that to tag the
> qt-4 ebuild as a virtual and then we should get better behavior due
> to virtual lookahead mechanism that has been implemented for bug
> 141118 [3]. In the absence of PROPERTIES=virtual support, we'd have
> to use a more complex approach such as the "avoid redundant
> upgrades" algorithm suggested for bug 260225 [4].
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=161953
> [2]
> http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
> [3] http://bugs.gentoo.org/show_bug.cgi?id=141118
> [4] http://bugs.gentoo.org/show_bug.cgi?id=260225
> - --
> Thanks,
> Zac

This seems another option but, implementing previous one, would allow to
cover more possible cases 

Best regards :-)

Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pacho Ramos wrote:
> El lun, 02-03-2009 a las 13:01 -0800, Zac Medico escribió:
>> || ( ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) x11-libs/qt:4 )
>>
>> It's a variation of bug 161953 [1]. For this particular variation,
>> at the moment I don't think there's a good way to distinguish that
>> the choice on the left is the better choice. 
> 
>>From my point of view, I think that portage should do something like
> calculating how much a dep is already in the system, for example, in
> this case, I have 50% of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 )
> already installed on my system while 0% of x11-libs/qt:4. Then,
> ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) would be a better option
> because, hopefully, a user that has already installed a portion of this
> dep, will prefer to maintain it installed
> 
> But, this is only theoretical as I am not a programmer and I don't know
> if this could be implemented

You're right. It's easy to says it in words but if you tried to
actually implementing you'd find that the PROPERTIES=virtual concept
simplifies the problem a lot and makes it possible to optimally
solve some cases of bug 141118 that couldn't otherwise be solved
optimally without the information that PROPERTIES=virtual provides.

What we're talking about is a cost calculation and in order for the
cost calculation to be as accurate as possible, we need to know
which ebuilds have zero-cost to install (the virtual ones do not
install anything directly so they are considered to have zero-cost
in themselves). If you consider all ebuilds to have equal cost then
your calculation won't be as accurate as it could be. Knowing which
ebuilds are virtual gives a hint to the resolver that it should
perform a "lookahead" in the cost calculation.

We could implement a similar lookahead mechanism for non-virtual
ebuilds, but it's more useful for the virtual ones. Backtracking
(which isn't implemented yet but is planned for bug 1343) would also
be useful for implementing additional cost optimizations (like the
one for bug 260225).
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmthAwACgkQ/ejvha5XGaP0WwCgkpqDyXQTKRbrBU9ncvfmOIoo
UlwAoOmIu1RCt7/wfSgTrMDCCx8t6IcP
=CVC5
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] emerge prefers to install x11-libs/qt:4 instead of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) even when x11-libs/qt-gui:4 is already installed

[Pacho Ramos]

El mar, 03-03-2009 a las 11:25 -0800, Zac Medico escribió:
> 
> You're right. It's easy to says it in words but if you tried to
> actually implementing you'd find that the PROPERTIES=virtual concept
> simplifies the problem a lot and makes it possible to optimally
> solve some cases of bug 141118 that couldn't otherwise be solved
> optimally without the information that PROPERTIES=virtual provides.
> 
> What we're talking about is a cost calculation and in order for the
> cost calculation to be as accurate as possible, we need to know
> which ebuilds have zero-cost to install (the virtual ones do not
> install anything directly so they are considered to have zero-cost
> in themselves). If you consider all ebuilds to have equal cost then
> your calculation won't be as accurate as it could be. Knowing which
> ebuilds are virtual gives a hint to the resolver that it should
> perform a "lookahead" in the cost calculation.
> 
> We could implement a similar lookahead mechanism for non-virtual
> ebuilds, but it's more useful for the virtual ones. Backtracking
> (which isn't implemented yet but is planned for bug 1343) would also
> be useful for implementing additional cost optimizations (like the
> one for bug 260225).
> - --
> Thanks,
> Zac

No problem. Thanks for the explanation :-)