-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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). > >> Other developers state that users are not interested in such >> implementation details, or that forced choice through >> REQUIRED_USE is too much of a hassle. This results in current >> ebuilds such as quassel to not make it clear that qt4 is an >> option. >> >> This goes against the principle of least surprise, as well as >> against QA recommendations. I would like to hear specifically >> from QA about how we should proceed, but comments from the wider >> developer community are also welcome. > > As far as I understand this is done to simplify user's experiense: > usually people set both USE="qt4 qt5" in global make.conf, because > they want qt in the first place. > > This policy will allow to USE both qt versions whichever is > available preferring newer one. Quite reasonable approach. > Alternatives (^^() and ??()) will require micromanagement (e.g. > pagkage.use.conf) for dozens if not hundreds of packages for no > good reason. If someone still needs to override such policy (e.g. > to use qt4 when both are available), this can be done by > per-package configuration. > > My idea is that packages should be fully controllable, but choises > of default behaviour should be done so, that in most cases > micromanagement will not be necessary. > > I like this qt policy and I'm not sure if it violates any current > rule. But even in such case this rule should be fixed. Moreover, > this problem is not limited for qt: we have exactly the same issue > with gtk2 vs gtk3 and probably some other technologies. > > Of course in theory it is possible to build package with two sets > of binaries supporting both qt4 and qt5, but I see little > practical need for that. > > So I propose to add somewhere to devmanual/policies the following > recommendation: "If package supports several versions of the same > technology (e.g. qt4 and qt5) and more than one is enabled by USE > flags, ebuild should prefer the later one (in terms of technology > generation).". > > Best regards, Andrew Savchenko > +1 - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVvxlqAAoJEAEkDpRQOeFwRqAP/jLkyzsJ0lPind06f8YvQ4aF Nog8g2pJHJUYXryJwCZpedj4Ju8QWnlE9qOLFO/PvKjNq1AddI7PB/BpUAK1HBuq 9T319lQttGyZAFqEeYm3j1c7IcQInNSXaGLJnLVw19UWgUg1ZuTxiec7XJ7Qovmy D1BdZrMSVhxzSfCKN0kGM3IDxgInVWnEhPCiqDzDMT/U9j1K1sOFA/77/M+HbEvp LP26R/ICdznLNTRqAQxBn6TnZ0D6LMp+ngWCvSa07XCyn3O2K1cQA012l3hQ4/Jb +GP3mk6UM3rhn5saZ+2nJM5axFNylTFcJnqJFjU6//Q7q3C0Xh4sEuu8n3ywgiG4 8Mmta0i9TgGcIjfnCcDpMO6Yvs1g79Hgg3A87tCzJEaYRXWlHjGY+YsoYVIvPS6d qNdhG8+/8hhQUQy4gcmT7M5HZVkMj/hmju+X9bCPbDrJY6Xii90ZbvCZGiPBAJbm VebTPg5CAzybhqtYAOiygLKMqh1Sw8LrFlBSAMJpLr89CHN0ODuzQp+Rho6rYcp0 t2J8AWJHW2XJ8TePvDpCDkEog83c1sSxKPqsu8AHTPcw+Bvol4vpmUsv0BQlp9aa F4ZXxccqTzbZtwJ9x7jBGjlBl6H4Bu0OE/y7nUPG9aTldxMfnEgJeEktUtpAlWCu fYSYVLjlNUl9OtL/ElnI =fRV1 -----END PGP SIGNATURE-----
