Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 02:38 AM, Ben de Groot wrote: > On 4 August 2015 at 22:56, Ian Stakenvicius > wrote: >> 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. > > I'm not aware we have such a package, but I may be overlooking > something. Either way, I think it is a dangerous road to go down > that way. > I'm not aware of any either, although I haven't done a comprehensive audit of the tree to find out. I would find it unlikely that any such package exists. The thing is, we're already travelling that road (have been for a long while), and IMO there is very little "cost" to travelling this road compared to the so-called "proper" solution of forcing off one flag or the other, ESPECIALLY when we are likely to have both flags default-on soon in the generic desktop profile as was posted earlier. If we do go the REQUIRED_USE="^^" route on packages, then I think it would be best that we change the 'desktop' and other profiles s.t. maintainers need to add their package with whichever flag should be enabled (qt4 or qt5) to package.use, rather than having the qt* flag(s) globally enabled in the profile -- otherwise we end up with end-users having to deal with it. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXCfk4ACgkQAJxUfCtlWe1CswEA0e4c/gRSbjg0b858+uVFc+z2 +05WUPjFsPpfXrdPs3wA/2r0PyitPRoZAWPWBKm8LhMAC5YIHtjhWA7kh2LTImAQ =gyeU -END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
On 5 August 2015 at 03:09, Davide Pesavento wrote: > On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot wrote: >> On 4 August 2015 at 04:20, Rich Freeman wrote: >>> [...] >>> Gentoo should be the best of both worlds. We should give users the >>> power to tweak things, but we shouldn't force them to play with config >>> files all day long just to have a functional system. If users want to >>> care we let them care instead of telling them "don't touch" like most >>> other distros, but if they don't care we still provide reasonable >>> defaults. >> >> And that is exactly what we do. The kde profile enables qt4, the >> plasma profile enables qt5, the other profiles have no qt* useflags >> enabled. These are reasonable defaults. >> > > As tetromino pointed out, this is very far from the real current situation. Indeed, I was wrong here. We will need another solution. >> Of course some users will proceed to enable both qt4 and qt5 globally >> in their make.conf, but I don't think it is unreasonable to expect >> them to then deal with adding exceptions to package.use for those >> packages where exactly-one-of is required. >> >> In my opinion, this is the way Gentoo has always worked, and we should >> simply recommend users to only set one of the qt* useflags as globally >> enabled, if they want to prevent such micro-management. Hiding the qt4 >> option is in my opinion the wrong solution around people complaining >> after they have consciously enabled both flags. >> >> If this is not acceptable (or "absolutely unusable" as one dev put >> it), then we need a proper solution, which a) will not hide the qt4 >> option, and b) will prevent triggering required_use blockage by >> choosing qt5 over qt4 in case both are enabled, while c) informing the >> user about this. This probably requires new eclass or even EAPI >> functionality. >> > > Please go ahead and design and implement such functionality (a sort of > REQUIRED_USE defaults). Something along the lines of PYTHON_TARGETS could work. But personally, I'm happy with REQUIRED_USE. > In the meantime, we will apply the policies > written in the Qt project wiki page. Except for the one that is wrong. >> In the meantime, we should stick with the policies adopted at the qt3 >> to qt4 transition (explicit versioned useflags) and let the user deal >> with per-package management if they enable both flags. >> > > We didn't have REQUIRED_USE at the time of the qt3->qt4 transition, so > this point is completely moot. We had something worse. That didn't prevent us from using it tho. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 4 August 2015 at 22:56, Ian Stakenvicius wrote: > 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. I'm not aware we have such a package, but I may be overlooking something. Either way, I think it is a dangerous road to go down that way. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot wrote: > On 4 August 2015 at 04:20, Rich Freeman wrote: >> [...] >> Gentoo should be the best of both worlds. We should give users the >> power to tweak things, but we shouldn't force them to play with config >> files all day long just to have a functional system. If users want to >> care we let them care instead of telling them "don't touch" like most >> other distros, but if they don't care we still provide reasonable >> defaults. > > And that is exactly what we do. The kde profile enables qt4, the > plasma profile enables qt5, the other profiles have no qt* useflags > enabled. These are reasonable defaults. > As tetromino pointed out, this is very far from the real current situation. > Of course some users will proceed to enable both qt4 and qt5 globally > in their make.conf, but I don't think it is unreasonable to expect > them to then deal with adding exceptions to package.use for those > packages where exactly-one-of is required. > > In my opinion, this is the way Gentoo has always worked, and we should > simply recommend users to only set one of the qt* useflags as globally > enabled, if they want to prevent such micro-management. Hiding the qt4 > option is in my opinion the wrong solution around people complaining > after they have consciously enabled both flags. > > If this is not acceptable (or "absolutely unusable" as one dev put > it), then we need a proper solution, which a) will not hide the qt4 > option, and b) will prevent triggering required_use blockage by > choosing qt5 over qt4 in case both are enabled, while c) informing the > user about this. This probably requires new eclass or even EAPI > functionality. > Please go ahead and design and implement such functionality (a sort of REQUIRED_USE defaults). In the meantime, we will apply the policies written in the Qt project wiki page. > In the meantime, we should stick with the policies adopted at the qt3 > to qt4 transition (explicit versioned useflags) and let the user deal > with per-package management if they enable both flags. > We didn't have REQUIRED_USE at the time of the qt3->qt4 transition, so this point is completely moot.
Re: [gentoo-dev] useflag policies
On Mon, Aug 3, 2015 at 10:10 PM, Alexandre Rostovtsev wrote: > On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote: >> On 4 August 2015 at 04:20, Rich Freeman wrote: >> > [...] >> > Gentoo should be the best of both worlds. We should give users the >> > power to tweak things, but we shouldn't force them to play with config >> > files all day long just to have a functional system. If users want to >> > care we let them care instead of telling them "don't touch" like most >> > other distros, but if they don't care we still provide reasonable >> > defaults. >> >> And that is exactly what we do. The kde profile enables qt4, the >> plasma profile enables qt5, the other profiles have no qt* useflags >> enabled. These are reasonable defaults. > > That is not correct. The desktop profile enables qt4, because it is a > reasonable default (for qt-only packages, USE=-qt4 means "don't build > any gui", but desktop users always expect some kind of a gui by > default, whether it's gtk or qt*.) > > The result is that qt4 is enabled in child profiles of desktop - gnome > and kde and plasma. Since plasma enables qt5 and does nothing with qt4, > you have all qt versions enabled there. > > And when popular qt5-only, gui-optional packages appear in the tree, we > will need to enable qt5 in desktop profile too. Exactly, +1.
Re: [gentoo-dev] useflag policies
-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-
Re: [gentoo-dev] useflag policies
On Tue, 2015-08-04 at 11:59 +0800, Ben de Groot wrote: > On 4 August 2015 at 04:20, Rich Freeman wrote: > > [...] > > Gentoo should be the best of both worlds. We should give users the > > power to tweak things, but we shouldn't force them to play with config > > files all day long just to have a functional system. If users want to > > care we let them care instead of telling them "don't touch" like most > > other distros, but if they don't care we still provide reasonable > > defaults. > > And that is exactly what we do. The kde profile enables qt4, the > plasma profile enables qt5, the other profiles have no qt* useflags > enabled. These are reasonable defaults. That is not correct. The desktop profile enables qt4, because it is a reasonable default (for qt-only packages, USE=-qt4 means "don't build any gui", but desktop users always expect some kind of a gui by default, whether it's gtk or qt*.) The result is that qt4 is enabled in child profiles of desktop - gnome and kde and plasma. Since plasma enables qt5 and does nothing with qt4, you have all qt versions enabled there. And when popular qt5-only, gui-optional packages appear in the tree, we will need to enable qt5 in desktop profile too. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] useflag policies
On 4 August 2015 at 04:20, Rich Freeman wrote: > [...] > Gentoo should be the best of both worlds. We should give users the > power to tweak things, but we shouldn't force them to play with config > files all day long just to have a functional system. If users want to > care we let them care instead of telling them "don't touch" like most > other distros, but if they don't care we still provide reasonable > defaults. And that is exactly what we do. The kde profile enables qt4, the plasma profile enables qt5, the other profiles have no qt* useflags enabled. These are reasonable defaults. Of course some users will proceed to enable both qt4 and qt5 globally in their make.conf, but I don't think it is unreasonable to expect them to then deal with adding exceptions to package.use for those packages where exactly-one-of is required. In my opinion, this is the way Gentoo has always worked, and we should simply recommend users to only set one of the qt* useflags as globally enabled, if they want to prevent such micro-management. Hiding the qt4 option is in my opinion the wrong solution around people complaining after they have consciously enabled both flags. If this is not acceptable (or "absolutely unusable" as one dev put it), then we need a proper solution, which a) will not hide the qt4 option, and b) will prevent triggering required_use blockage by choosing qt5 over qt4 in case both are enabled, while c) informing the user about this. This probably requires new eclass or even EAPI functionality. In the meantime, we should stick with the policies adopted at the qt3 to qt4 transition (explicit versioned useflags) and let the user deal with per-package management if they enable both flags. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 03/08/2015 22:20, Rich Freeman wrote: > On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski wrote: >> On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: >> | The approach qt4=qt4 >> | and qt5=qt5 seems simpler on the surface, but it means that users end >> | up having to set tons of per-package configurations when they don't >> | actually care which one they use, >> >> I will risk a thesis that if they didn't care, they wouldn't have chosen >> Gentoo... >> > > Obviously there are many reasons people use Gentoo, but here is my > perspective on this. > > The value of Gentoo is that it gives you a LOT of power to tweak > individual package configurations, without the requirement to do this > for everything. There are packages that I carefully configure USE > flags for, CFLAGS for, epatch_user, and so on. Heck, some packages I > run in containers where I can carefully control almost all aspects of > their environment. Then on the same host I'll have screen and bash > and a million other packages installed where exact configuration is > not critical, and so I want it to "just work." If I wanted to > micromanage everything I might as well run Linux From Scratch. > > Gentoo should be the best of both worlds. We should give users the > power to tweak things, but we shouldn't force them to play with config > files all day long just to have a functional system. If users want to > care we let them care instead of telling them "don't touch" like most > other distros, but if they don't care we still provide reasonable > defaults. > +1 One of the most powerful aspects of ebuilds is the ability to not have to control something the user does not want to. I use Gentoo because I can control what I wish and like Rich the bits I want to control are a small fraction of the whole. When a dev says "I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo", there is a place for that but it is by no means the general case. We DO accommodate the control freaks, we let them USE="-*" and let them keep all the tiny shards. But the truth is far more subtle than a care-all/care-none scenario. I say stick with reasonable defaults, and for better or worse, that includes "use highest version in ACCEPT_KEYWORDS unless user says otherwise" -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] useflag policies
On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski wrote: > On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: > | The approach qt4=qt4 > | and qt5=qt5 seems simpler on the surface, but it means that users end > | up having to set tons of per-package configurations when they don't > | actually care which one they use, > > I will risk a thesis that if they didn't care, they wouldn't have chosen > Gentoo... > Obviously there are many reasons people use Gentoo, but here is my perspective on this. The value of Gentoo is that it gives you a LOT of power to tweak individual package configurations, without the requirement to do this for everything. There are packages that I carefully configure USE flags for, CFLAGS for, epatch_user, and so on. Heck, some packages I run in containers where I can carefully control almost all aspects of their environment. Then on the same host I'll have screen and bash and a million other packages installed where exact configuration is not critical, and so I want it to "just work." If I wanted to micromanage everything I might as well run Linux From Scratch. Gentoo should be the best of both worlds. We should give users the power to tweak things, but we shouldn't force them to play with config files all day long just to have a functional system. If users want to care we let them care instead of telling them "don't touch" like most other distros, but if they don't care we still provide reasonable defaults. -- Rich
Re: [gentoo-dev] useflag policies
Maciej Mrozowski wrote: > On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: > | The approach qt4=qt4 > | and qt5=qt5 seems simpler on the surface, but it means that users end > | up having to set tons of per-package configurations when they don't > | actually care which one they use, > > I will risk a thesis that if they didn't care, they wouldn't have chosen > Gentoo... > > regards > MM > > You may lose that one if I'm seeing your point correctly. See Alan and my earlier replies. I have both qt4 and qt5 set and I leave which is best to use to the devs to control in the ebuild. If for example qt5 does not work well for a package, let the ebuild pick qt4 for that package. If qt5 works reliably, then build with qt5. If I have a problem with it, then I can set it in package.use if needed, doesn't build or function correctly or I want qt5 even if it isn't stable. As things switch to qt5 more, I don't have to do anything except let the updates roll out as they become stable and the dev sets that in the ebuild. Keep in mind, devs already do a LOT of the selection process. Otherwise, we could set any and every USE flag and package combination there is without any restrictions. In other words, we could have USE flag soup even if it is known that two or more USE flags clash. As it is, if a dev knows two flags clash, we get a nifty error message and then we get to figure out how to get it to work right, sometimes portage's error message is cryptic to say the least. If I took your point wrong, my apologies. Lowly user. Dale :-) :-)
Re: [gentoo-dev] useflag policies
On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... regards MM
Re: [gentoo-dev] useflag policies
-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-
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2015 12:12 PM, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko > wrote: >> >> This is a clean solution for developers and maintainers, but not >> for ordinary users — they will confused by "qt qt4 qt5": "what >> is 'qt', how is it different from 'qt4' and 'qt5'. What you are >> really doing is implementing second-level USE flags, while they >> were supposed to be linear. > > No argument that it isn't intuitive, but setting USE=qt and > forgetting about it certainly seems more user-friendly than setting > qt4/qt5 on individual packages and worrying about which is better > where. To some extent the current qt policy accomplishes this, but > it sacrifices control when users actually do want it. > > I'm a bit torn on the issue myself, but just telling users to set > USE=qt and forget about it unless you really care seems pretty > simple to me. The documentation for USE=qt4/qt5 could say "this is > an advanced setting for users who want to prefer the qt4 > implementation over others - set USE=qt if all you care about is qt > support." > I like this idea. USE=qt for all apps that optionally support or need it, qt4/qt5 for apps that support both. We can default to qt5 and users can still choose qt4 if they prefer it. - -- 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 iQIcBAEBCAAGBQJVvxjcAAoJEAEkDpRQOeFwbIsQAJeCSW9NHUFyXirEhh/pL7cP Vc5F6bgxZhJ1svHiCxMAQuFz5POG/yxjq6iAwjtCaDaWBDj/HbSDe69Pu0HBcCkK ezb2AJTtacvkWDxlJhH4H9m7QB3M9/XWlKlfMAhKnDEaSFS/yieR578LE1sNd2aF A9JditTliVqmRr3DYNvT4JlqGIBJyU43gR75gW2gHyWE0FTZ4Rv8k6DQHJuseFb6 OvWWrDCKZQZqLmLIvpvz1ksyXuFis8qqCPLws37awo56kjT8jDJ+kdulwFGdvxui zrau+MtufhDwehVsVKKe1j/6dhVnmOqlIZd3H7Pule9jFsH6AGRN4s2dL2bp9vqi WdmQI8B6eDvdUK0Il1+zd7V1Uq8DXIYpTlOYrUHtnAlyaT8ln7FqojSKODASZ/10 LkJQ9SLv7ej6nQLnkYe4F1FQqssPqGe4v2tAZcFVu2pYda3KCP7PJKT70oFtzwrQ 76jVgp5Ryp/cbZrM2tOEcvb/3kTXDHDW2Wavh+VV7XwBmTvXoXqZas+eHMMtbyDJ 1cofAFRvu6HWnITTg3ZPoiQbm5Sq4rjG7aUvkyUxIoC8YzhXdHOTBpaYaFe6nZ/f 45e7lHq4iDsArmBn2BiF4kBKZh8I5xMY1/K10mC8/4emBS3NHbafOUKqujCCqLMj dhh/jF4gLzALPIDGXBRp =j7X5 -END PGP SIGNATURE-
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 11:30, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot wrote: >>> I want to use fooplayer and bargrapher which are two qt-based >>> applications. fooplayer only supports qt4, and bargrapher only >>> supports qt5. What USE flags should I set, without restorting to >>> per-package flags? >> >> These packages would not have useflags, as they only use one toolkit. >> > > What if qt support is optional, and I do/don't want it enabled? Users who don't care, simply follow the defaults as set by the package maintainer or profile. Users who do care wouldn't mind adding a rule to their package.use. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 01:33, Andrew Savchenko wrote: > On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: > [...] > 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. See https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies under 1.4 and 1.5. QA has spoken out pretty clearly against unversioned gtk or qt useflags, and in favour of explicit versioned useflags. Dropping the explicit qt4 useflag in these cases goes against (at least the spirit of) this. > [...] > 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).". If we adopt this, we should make sure the users understand this policy, because it hides certain details from the user. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On Sun, Aug 2, 2015 at 11:24 PM, Ben de Groot wrote: >> I want to use fooplayer and bargrapher which are two qt-based >> applications. fooplayer only supports qt4, and bargrapher only >> supports qt5. What USE flags should I set, without restorting to >> per-package flags? > > These packages would not have useflags, as they only use one toolkit. > What if qt support is optional, and I do/don't want it enabled? -- Rich
Re: [gentoo-dev] useflag policies
On 3 August 2015 at 09:37, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer wrote: >> I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why >> not >> USE="X" ?) which then does different things based on another useflag, >> sometimes. Maybe. It's horribly inconsistent and even might change result >> over >> time, which is not very user-friendly. > > The problem is that this approach breaks down with scenarios which are > likely to be commonplace. > > I want to use fooplayer and bargrapher which are two qt-based > applications. fooplayer only supports qt4, and bargrapher only > supports qt5. What USE flags should I set, without restorting to > per-package flags? These packages would not have useflags, as they only use one toolkit. > Then I also install klunkybrowser which supports > both qt4 and qt5 but not at the same time, so how should I manage my > flags for that? Set your global default in make.conf as either qt4 or qt5. If you want to deviate from that for some package, you can set per package use flags. Easy peasy. Clear and straightforward. Principle of least surprise. > The current qt policy just has each package support only one version > using USE=qt No, that is not at all the case. We have banned a simple qt useflag since many years (which is also the QA policy). We have been using versioned qt3, qt4, qt5 useflags. > and while it denies user choice for klunkybrowser it is > at least simple. The alternative of "qt means I don't care what > version" is also simple Except many users do care. I don't see the benefit in changing the way we used to do this. > The approach qt4=qt4 > and qt5=qt5 seems simpler on the surface, but it means that users end > up having to set tons of per-package configurations when they don't > actually care which one they use, and it also doesn't necessarily hint > to users which will give them the best experience on each package. If they don't care, they can simply follow the defaults and not set any qt4 or qt5 useflags in make.conf. > Right now you can get away with just USE="qt4 -qt5" because we don't > have many qt5-only packages in the tree As I said before, this is of no consequence, as there would be no mutually exclusive qt4 and qt5 useflags anyway for those packages. The problem only appears with packages that force a choice between qt4 and qt5, and users that have enabled both useflags globally. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] useflag policies
On Sun, Aug 2, 2015 at 9:03 PM, Patrick Lauer wrote: > I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why not > USE="X" ?) which then does different things based on another useflag, > sometimes. Maybe. It's horribly inconsistent and even might change result over > time, which is not very user-friendly. The problem is that this approach breaks down with scenarios which are likely to be commonplace. I want to use fooplayer and bargrapher which are two qt-based applications. fooplayer only supports qt4, and bargrapher only supports qt5. What USE flags should I set, without restorting to per-package flags? Then I also install klunkybrowser which supports both qt4 and qt5 but not at the same time, so how should I manage my flags for that? The current qt policy just has each package support only one version using USE=qt and while it denies user choice for klunkybrowser it is at least simple. The alternative of "qt means I don't care what version" is also simple - the klunkybrowser maintainer would pick the best default and those who care can override it. The approach qt4=qt4 and qt5=qt5 seems simpler on the surface, but it means that users end up having to set tons of per-package configurations when they don't actually care which one they use, and it also doesn't necessarily hint to users which will give them the best experience on each package. Right now you can get away with just USE="qt4 -qt5" because we don't have many qt5-only packages in the tree (I actually have one I've been holding off on introducing due to qt5 not being in the tree until recently). When that changes the mutually-exclusive flags approach will be very painful. -- Rich
Re: [gentoo-dev] useflag policies
On Monday 03 August 2015 00:34:51 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 and a > REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice. Since qt4 and qt5 are both relatively 'heavy' dependencies and quite different in many ways (including differences in default styles) many users will want to stick with only one of those. The gtk 'solution' forced some ugly things like masking gtk+:3, gconf:3, ... and then selecting packages based on specific -r200 / -r300 revisions. So much work to avoid regressing into gtk3! (Which is especially frustrating because *dbus* has wrong dependencies just so that gtk/gnome apps using dconf can save config ... ) > > 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. I find setting USE="qt4 -qt5" a lot more obvious than having USE="qt" (why not USE="X" ?) which then does different things based on another useflag, sometimes. Maybe. It's horribly inconsistent and even might change result over time, which is not very user-friendly. > > 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. I would prefer having qt4 and qt5 useflags independent, and no generic qt useflag.
Re: [gentoo-dev] useflag policies
On Sunday 02 August 2015 22:22:28 Ciaran McCreesh wrote: > On Sun, 02 Aug 2015 17:14:47 -0400 > > NP-Hardass wrote: > > ^^ has the pleasant side effect of being easier to read, as a user. > > The user receives a message saying "at-most-one-of" instead of some > > convoluted other expression that they don't understand. > > > > I am all for the use of ^^ add the default for this reason. > > > > Additionally, ?? has the same effect of being easy to understand as > > the description in the error message is in plain English. > > If you cared about readability, you'd use pkg_pretend. No.
Re: [gentoo-dev] useflag policies
On Sun, 02 Aug 2015 17:14:47 -0400 NP-Hardass wrote: > ^^ has the pleasant side effect of being easier to read, as a user. > The user receives a message saying "at-most-one-of" instead of some > convoluted other expression that they don't understand. > > I am all for the use of ^^ add the default for this reason. > > Additionally, ?? has the same effect of being easy to understand as > the description in the error message is in plain English. If you cared about readability, you'd use pkg_pretend. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] useflag policies
^^ has the pleasant side effect of being easier to read, as a user. The user receives a message saying "at-most-one-of" instead of some convoluted other expression that they don't understand. I am all for the use of ^^ add the default for this reason. Additionally, ?? has the same effect of being easy to understand as the description in the error message is in plain English. -- NP-Hardass On August 2, 2015 12:34:51 PM EDT, 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 and a >REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest >choice. > >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. > >-- >Cheers, > >Ben | yngwin >Gentoo developer -- NP-Hardass
Re: [gentoo-dev] useflag policies
On Sun, Aug 2, 2015 at 12:12 PM, Rich Freeman wrote: > On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko wrote: >> >> This is a clean solution for developers and maintainers, but not >> for ordinary users — they will confused by "qt qt4 qt5": "what is >> 'qt', how is it different from 'qt4' and 'qt5'. What you are really >> doing is implementing second-level USE flags, while they were >> supposed to be linear. > > No argument that it isn't intuitive, but setting USE=qt and forgetting > about it certainly seems more user-friendly than setting qt4/qt5 on > individual packages and worrying about which is better where. To some > extent the current qt policy accomplishes this, but it sacrifices > control when users actually do want it. No, it does not. You can still control whether you want qt4 or qt5 on a per-package basis. The difference is that users that don't care about this level of control are not forced to make a choice for every package due to REQUIRED_USE conflicts. Unless I'm missing something...
Re: [gentoo-dev] useflag policies
On Sun, Aug 2, 2015 at 10:27 AM, Michał Górny wrote: > Dnia 2015-08-03, o godz. 00:34:51 > Ben de Groot napisał(a): > >> 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 and a >> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice. >> >> 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. > > Long story short, this is USE=gtk once again. GNOME team had a > policy that handled the case cleanly and QA outvoted it in favor of > Qt-like policy. Then Qt team figured out their policy was unfriendly, > and 'fixed' it with this ugly hack... Except that it's not a "ugly hack", but it's in fact recommended by the devmanual (ulm already quoted the relevant text). I'd agree that it's not ideal either (but so far I haven't seen any ideal solution being proposed). > As I see it, this is a major failure of using toolkit-version oriented > flags rather than feature-oriented flags. Possibilities compared: I could agree with this. So, back to USE=gui? A USE_EXPAND maybe? > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > team policy. USE=qt would mean 'any version of Qt, if optional', and > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > obligatory, no USE=qt would apply. If only one Qt version would be > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > package.use cruft. > I could agree in principle. However this would be a major tree-wide change, and should happen as quickly as possible to avoid creating even more confusion for users. Plus, who is willing to do all the work? (hint: I'm not) ...so, I don't think this solution is practical.
Re: [gentoo-dev] useflag policies
Dnia 2015-08-02, o godz. 21:50:25 Andrew Savchenko napisał(a): > On Sun, 2 Aug 2015 20:35:27 +0200 Michał Górny wrote: > > Dnia 2015-08-02, o godz. 21:21:03 > > Andrew Savchenko napisał(a): > > > > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: > > > > Long story short, this is USE=gtk once again. GNOME team had a > > > > policy that handled the case cleanly and QA outvoted it in favor of > > > > Qt-like policy. Then Qt team figured out their policy was unfriendly, > > > > and 'fixed' it with this ugly hack... > > > > > > > > As I see it, this is a major failure of using toolkit-version oriented > > > > flags rather than feature-oriented flags. Possibilities compared: > > > > > > > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE > > > > issues. However, it's ugly: USE='qt4 qt5' may now mean either both > > > > toolkits or one of them. In the latter case, we have two flag > > > > combinations (= two different binary packages) that mean the same. > > > > Additionally, USE='-qt4 -qt5' may mean both none of them or one of > > > > them. If the latter, yet another case of redundant binary package. > > > > > > > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better > > > > for binary packages. However, it may mean that user will have to > > > > randomly adjust flags per-package. Which may end up sucking even more > > > > with new Qt versions being introduced and package.use being full of > > > > random '-qt4' and stuff. > > > > > > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > > > > team policy. USE=qt would mean 'any version of Qt, if optional', and > > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > > > > obligatory, no USE=qt would apply. If only one Qt version would be > > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > > > > package.use cruft. > > > > > > This is a clean solution for developers and maintainers, but not > > > for ordinary users — they will confused by "qt qt4 qt5": "what is > > > 'qt', how is it different from 'qt4' and 'qt5'. > > > > This can be easily fixed via USE flag descriptions. And unlike with > > your solution, the descriptions can be globally consistent. > > > > > What you are really > > > doing is implementing second-level USE flags, while they were > > > supposed to be linear. > > > > Please support such claims with references. > > A reference from your previous e-mail: > > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: > [...] > > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > > > > team policy. USE=qt would mean 'any version of Qt, if optional', and > > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > > > > obligatory, no USE=qt would apply. If only one Qt version would be > > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > > > > package.use cruft. > > You're proposing "qt" as a top level USE flag, while "qt4/qt5" will > be in your opinion optional clarifying USE flags. This way we have > second-level hierarchy. I meant the claim that USE flags are supposed to be linear. -- Best regards, Michał Górny pgpngcUpu39iK.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] useflag policies
On Sun, Aug 2, 2015 at 2:21 PM, Andrew Savchenko wrote: > > This is a clean solution for developers and maintainers, but not > for ordinary users — they will confused by "qt qt4 qt5": "what is > 'qt', how is it different from 'qt4' and 'qt5'. What you are really > doing is implementing second-level USE flags, while they were > supposed to be linear. No argument that it isn't intuitive, but setting USE=qt and forgetting about it certainly seems more user-friendly than setting qt4/qt5 on individual packages and worrying about which is better where. To some extent the current qt policy accomplishes this, but it sacrifices control when users actually do want it. I'm a bit torn on the issue myself, but just telling users to set USE=qt and forget about it unless you really care seems pretty simple to me. The documentation for USE=qt4/qt5 could say "this is an advanced setting for users who want to prefer the qt4 implementation over others - set USE=qt if all you care about is qt support." -- Rich
Re: [gentoo-dev] useflag policies
On Sun, 2 Aug 2015 20:35:27 +0200 Michał Górny wrote: > Dnia 2015-08-02, o godz. 21:21:03 > Andrew Savchenko napisał(a): > > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: > > > Long story short, this is USE=gtk once again. GNOME team had a > > > policy that handled the case cleanly and QA outvoted it in favor of > > > Qt-like policy. Then Qt team figured out their policy was unfriendly, > > > and 'fixed' it with this ugly hack... > > > > > > As I see it, this is a major failure of using toolkit-version oriented > > > flags rather than feature-oriented flags. Possibilities compared: > > > > > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE > > > issues. However, it's ugly: USE='qt4 qt5' may now mean either both > > > toolkits or one of them. In the latter case, we have two flag > > > combinations (= two different binary packages) that mean the same. > > > Additionally, USE='-qt4 -qt5' may mean both none of them or one of > > > them. If the latter, yet another case of redundant binary package. > > > > > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better > > > for binary packages. However, it may mean that user will have to > > > randomly adjust flags per-package. Which may end up sucking even more > > > with new Qt versions being introduced and package.use being full of > > > random '-qt4' and stuff. > > > > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > > > team policy. USE=qt would mean 'any version of Qt, if optional', and > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > > > obligatory, no USE=qt would apply. If only one Qt version would be > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > > > package.use cruft. > > > > This is a clean solution for developers and maintainers, but not > > for ordinary users — they will confused by "qt qt4 qt5": "what is > > 'qt', how is it different from 'qt4' and 'qt5'. > > This can be easily fixed via USE flag descriptions. And unlike with > your solution, the descriptions can be globally consistent. > > > What you are really > > doing is implementing second-level USE flags, while they were > > supposed to be linear. > > Please support such claims with references. A reference from your previous e-mail: > > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: [...] > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > > > team policy. USE=qt would mean 'any version of Qt, if optional', and > > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > > > obligatory, no USE=qt would apply. If only one Qt version would be > > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > > > package.use cruft. You're proposing "qt" as a top level USE flag, while "qt4/qt5" will be in your opinion optional clarifying USE flags. This way we have second-level hierarchy. Best regards, Andrew Savchenko pgpynq0aIG62y.pgp Description: PGP signature
Re: [gentoo-dev] useflag policies
Dnia 2015-08-02, o godz. 21:21:03 Andrew Savchenko napisał(a): > On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: > > Long story short, this is USE=gtk once again. GNOME team had a > > policy that handled the case cleanly and QA outvoted it in favor of > > Qt-like policy. Then Qt team figured out their policy was unfriendly, > > and 'fixed' it with this ugly hack... > > > > As I see it, this is a major failure of using toolkit-version oriented > > flags rather than feature-oriented flags. Possibilities compared: > > > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE > > issues. However, it's ugly: USE='qt4 qt5' may now mean either both > > toolkits or one of them. In the latter case, we have two flag > > combinations (= two different binary packages) that mean the same. > > Additionally, USE='-qt4 -qt5' may mean both none of them or one of > > them. If the latter, yet another case of redundant binary package. > > > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better > > for binary packages. However, it may mean that user will have to > > randomly adjust flags per-package. Which may end up sucking even more > > with new Qt versions being introduced and package.use being full of > > random '-qt4' and stuff. > > > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > > team policy. USE=qt would mean 'any version of Qt, if optional', and > > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > > obligatory, no USE=qt would apply. If only one Qt version would be > > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > > package.use cruft. > > This is a clean solution for developers and maintainers, but not > for ordinary users — they will confused by "qt qt4 qt5": "what is > 'qt', how is it different from 'qt4' and 'qt5'. This can be easily fixed via USE flag descriptions. And unlike with your solution, the descriptions can be globally consistent. > What you are really > doing is implementing second-level USE flags, while they were > supposed to be linear. Please support such claims with references. -- Best regards, Michał Górny pgpRtmlnq2ApC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] useflag policies
On Sun, 2 Aug 2015 19:27:02 +0200 Michał Górny wrote: > Long story short, this is USE=gtk once again. GNOME team had a > policy that handled the case cleanly and QA outvoted it in favor of > Qt-like policy. Then Qt team figured out their policy was unfriendly, > and 'fixed' it with this ugly hack... > > As I see it, this is a major failure of using toolkit-version oriented > flags rather than feature-oriented flags. Possibilities compared: > > USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE > issues. However, it's ugly: USE='qt4 qt5' may now mean either both > toolkits or one of them. In the latter case, we have two flag > combinations (= two different binary packages) that mean the same. > Additionally, USE='-qt4 -qt5' may mean both none of them or one of > them. If the latter, yet another case of redundant binary package. > > USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better > for binary packages. However, it may mean that user will have to > randomly adjust flags per-package. Which may end up sucking even more > with new Qt versions being introduced and package.use being full of > random '-qt4' and stuff. > > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > team policy. USE=qt would mean 'any version of Qt, if optional', and > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > obligatory, no USE=qt would apply. If only one Qt version would be > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > package.use cruft. This is a clean solution for developers and maintainers, but not for ordinary users — they will confused by "qt qt4 qt5": "what is 'qt', how is it different from 'qt4' and 'qt5'. What you are really doing is implementing second-level USE flags, while they were supposed to be linear. > However, as you can see QA has previously outvoted the clean policy for > USE=gtk. I don't see why it would decide otherwise for USE=qt*. > > -- > Best regards, > Michał Górny Best regards, Andrew Savchenko pgpsxPI4QzhzE.pgp Description: PGP signature
Re: [gentoo-dev] useflag policies
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 pgpPTFN6MFtrx.pgp Description: PGP signature
Re: [gentoo-dev] useflag policies
On 8/2/15 7:27 PM, Michał Górny wrote: > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > team policy. USE=qt would mean 'any version of Qt, if optional', and > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > obligatory, no USE=qt would apply. If only one Qt version would be > supported, no USE=qt4/qt5 would apply. Clean, sane and limited > package.use cruft. +1 > However, as you can see QA has previously outvoted the clean policy for > USE=gtk. I don't see why it would decide otherwise for USE=qt*. I wonder what was the reasoning for the QA decision you refer to. Do you have more details or archive references? FWIW I think decisions like that can be revisited. Now could be a good moment for that. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] useflag policies
Dnia 2015-08-03, o godz. 00:34:51 Ben de Groot napisał(a): > 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 and a > REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice. > > 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. Long story short, this is USE=gtk once again. GNOME team had a policy that handled the case cleanly and QA outvoted it in favor of Qt-like policy. Then Qt team figured out their policy was unfriendly, and 'fixed' it with this ugly hack... As I see it, this is a major failure of using toolkit-version oriented flags rather than feature-oriented flags. Possibilities compared: USE='qt4 qt5' without ^^ is easy to set since it is free of REQUIRED_USE issues. However, it's ugly: USE='qt4 qt5' may now mean either both toolkits or one of them. In the latter case, we have two flag combinations (= two different binary packages) that mean the same. Additionally, USE='-qt4 -qt5' may mean both none of them or one of them. If the latter, yet another case of redundant binary package. USE='qt4 qt5' with ^^/?? is cleaner from user perspective and better for binary packages. However, it may mean that user will have to randomly adjust flags per-package. Which may end up sucking even more with new Qt versions being introduced and package.use being full of random '-qt4' and stuff. What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME team policy. USE=qt would mean 'any version of Qt, if optional', and qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be obligatory, no USE=qt would apply. If only one Qt version would be supported, no USE=qt4/qt5 would apply. Clean, sane and limited package.use cruft. However, as you can see QA has previously outvoted the clean policy for USE=gtk. I don't see why it would decide otherwise for USE=qt*. -- Best regards, Michał Górny pgpCv2HAvQuOi.pgp Description: OpenPGP digital signature
[gentoo-dev] useflag policies
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 and a REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice. 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. -- Cheers, Ben | yngwin Gentoo developer
