-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/08/15 03:34 AM, Daniel Campbell (zlg) wrote:
> On 08/02/2015 10:33 AM, Andrew Savchenko wrote:
>> On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote:
>>> Recently some team members of the Qt project have adopted
>>> these ebuild policies:
>>> https://wiki.gentoo.org/wiki/Project:Qt/Policies
>>>
>>> I have an issue with the policy adopted under "Requires one of
>>> two Qt versions". In my opinion, in the case where a package
>>> offers a choice between qt4 or qt5, we should express this in
>>> explicit useflags
>
>> This is what the policy does: "Implement both qt4 and qt5 USE
>> flags"
>
>>> and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the
>>> clearest choice.
>
>> This will create insane amount of blockers if users have both
>> flags in make.conf (and this is a common scenario).
>
Why exactly do we need to force-off the use flag for the one that
won't be used, anyways? Yes, there are qt4 deps in VDB that likely
won't be necessary, which causes --depclean to not necessarily be able
to make -as clean- a system, but realistically this is pretty minor.
Also, i don't see why end-users are going to care; if they specify
USE="qt4 qt5" then they should expect the package to depend on both
sets of the qt deps.
As for the ambiguity of which one the package will use, I think we can
satisfy that the same way we do slots -- that is, the one with the
larger ${PV} (ie qt5) is the one that will be used when both are
available. Intuitive, simple, and the system "just works".
Are there any cases where things actually break if a package has both
flags enabled? IE, is three a package with IUSE="qt4 qt5" that when
both flags are enabled would build for qt5 only, and happens to be a
dependency atom of something else that needs it to have qt4 support?
That to me is the only case where a REQUIRED_USE needs to be set on a
package.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlXA0roACgkQAJxUfCtlWe0CMgD/QDNIoY5Ug2f3+6OwvpIX+KG3
EiF8jm7yhzgoWck4wE8A+wYqFvyKoAedjdNMR6JKfSTuKQLKj0/PoqPu3tqXfkcG
=l8Bx
-----END PGP SIGNATURE-----
