-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/08/15 08:58 AM, Sergey Popov wrote: > 11.08.2015 15:30, Michael Palimaka пишет: >> On 11/08/15 20:10, Sergey Popov wrote: >>> Err, i have read the whole thread and still does not get a >>> point, why i am wrong. >> >> You clearly have not. The reasoning behind Qt team's policy is >> described on the page and has been reiterated on this list. You >> are undermining what little confidence there is in the QA team by >> making decisions with no consultation about problems you do not >> understand. >> >>> It's old battle like we have beforce with "gtk" meaning "any >>> versions of GTK flag". This behaviour should be killed with >>> fire. >>> >>> Let's me reiterate some of the cases: >>> >>> 1. Package can be build without Qt GUI at all, but either Qt4 >>> or Qt5 can be chosen, but not both. >>> >>> Fix this with REQUIRED_USE, do not enable any of Qt flags by >>> default >> >> Problem: this requires manual intervention if the user has both >> qt4 and qt5 USE flags enabled. >> > > User choice of using USE flags is NOT a problem > >>> >>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 >>> is required, but not both >>> >>> Same thing here, different REQUIRED_USE operator. But - enable >>> one of the flags by default to ease life of users. >> >> Problem: this requires manual intervention if the user has both >> qt4 and qt5 USE flags enabled. > > Same here > >>> >>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME >>> TIME(if such package even exists?) >>> >>> Do not use REQUIRED_USE here, not needed. >>> >>> Now, please tell me, where am i wrong? >>> >> >> The problem is manual intervention is required if the user has >> both qt4 and qt5 USE flags enabled - and this is a common >> configuration. It is not acceptable to make a user manually add >> numerous package.use entries when all they want to do is install >> KDE. > > And here > >> I agree Qt's policy is not a perfect solution, but in the absence >> of some feature allowing a preference to be set when there is a >> conflict it's the best we've got. >> > > If you want to go this way, then please provide helper functions > in eclasses to set dependencies properly for all common use cases. > That will ease life both of developers and users. >
Why do you need this? #1, if you really want RDEPEND to only include the deps the package will actually use, then you do this: old: qt5? ( list of qt5 atoms ) qt4? ( list of qt4 atoms ) ..to new: qt5? ( list of qt5 atoms ) !qt5? ( qt4? ( list of qt4 atoms ) ) BUT I would advise against this. If a user has specified both qt4 and qt5 in USE, then I see no problem with the VDB having both qt4 and qt5 atoms listed as dependencies. End-users that want a clean VDB can just make sure they only enable one flag, but end-users that don't care will have packages that just work. > Leaving constructing of dependencies to developers in all cases > will cause only pain in your solution. It really wont, see above. At minimum, it's barely any more work than it is with a REQUIRED_USE based solution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXKDTkACgkQAJxUfCtlWe09QAD/ST47V7i08k09c8o+dgMx8hQP cRyBiTzxHKKtQ3aqmKIBAIdjBB4rGZLLMjiu9l0KfUOkOT1J+Z8oHPWQhzDPJpqv =LCgR -----END PGP SIGNATURE-----
