11.08.2015 17:56, Ian Stakenvicius пишет: > 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. >
great, in that case emerge --depclean becomes completely useless, because of unneeded vdb deps. Those DEPENDs that i have provided was at least consistent in terms of dependencies(that does not mean that they are not ugly, though) >> 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. > I repeat that i said earlier: if this voodoo magic will be hidden in some eclass - it is fine. If developers will be forced to add this depstring over and over again - it will be PITA. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
