Re: [gentoo-dev] [RFC] Handling of test USE flag in ebuilds
Am 16.09.2010 04:01, schrieb Samuli Suominen: On 09/15/2010 08:02 PM, Thomas Sachau wrote: From discussion on IRC, it seems, like there are different options, so i would like to clarify this policy: The test USE flag is (i am only talking about portage now, since i am most familar with it) an internal flag, which is added by portage for every ebuild and enabled/disabled based on FEATURES=test or not. It is not managed via USE= line in make.conf or package.use settings. So in handling and setting, it is pretty much the same as for the arch USE flags, which are also only internally used and added, but never exposed to the users. Now i see the opinion, that it should always be added to IUSE, when it is referenced in the ebuild. This adds it to the visible USE flags in emerge output (imho pointless, since it is no option, which can be enabled/disabled like the other USE flags), but otherwise does change nothing. Because of this, i would like to discourage the addition of test USE flag to IUSE, since it is just an internal USE flag, which should not be exposed to the user. Of course it should be exposed to user, it makes reading deptree a lot easier and helps resolving e.g. circular dependencies by temporarily disabling the flag for say, random dev-perl package. Which deptree are you talking about? The --tree output of portage does not show you any USE flag conditionals. Additionally, if you disable the flag with FEATURES=test enabled, test phases will fail, so those packages will fail to install, i dont think, that this is the better option. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Handling of test USE flag in ebuilds
From discussion on IRC, it seems, like there are different options, so i would like to clarify this policy: The test USE flag is (i am only talking about portage now, since i am most familar with it) an internal flag, which is added by portage for every ebuild and enabled/disabled based on FEATURES=test or not. It is not managed via USE= line in make.conf or package.use settings. So in handling and setting, it is pretty much the same as for the arch USE flags, which are also only internally used and added, but never exposed to the users. Now i see the opinion, that it should always be added to IUSE, when it is referenced in the ebuild. This adds it to the visible USE flags in emerge output (imho pointless, since it is no option, which can be enabled/disabled like the other USE flags), but otherwise does change nothing. Because of this, i would like to discourage the addition of test USE flag to IUSE, since it is just an internal USE flag, which should not be exposed to the user. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Handling of test USE flag in ebuilds
On 09/15/2010 08:02 PM, Thomas Sachau wrote: From discussion on IRC, it seems, like there are different options, so i would like to clarify this policy: The test USE flag is (i am only talking about portage now, since i am most familar with it) an internal flag, which is added by portage for every ebuild and enabled/disabled based on FEATURES=test or not. It is not managed via USE= line in make.conf or package.use settings. So in handling and setting, it is pretty much the same as for the arch USE flags, which are also only internally used and added, but never exposed to the users. Now i see the opinion, that it should always be added to IUSE, when it is referenced in the ebuild. This adds it to the visible USE flags in emerge output (imho pointless, since it is no option, which can be enabled/disabled like the other USE flags), but otherwise does change nothing. Because of this, i would like to discourage the addition of test USE flag to IUSE, since it is just an internal USE flag, which should not be exposed to the user. Of course it should be exposed to user, it makes reading deptree a lot easier and helps resolving e.g. circular dependencies by temporarily disabling the flag for say, random dev-perl package. But it would be nice if we wouldn't have to add it manually to the IUSE list, but Portage would do it for us. But at any rate, it needs to be visible.
