FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-15-2010, 05:02 PM
Thomas Sachau
 
Default 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
 
Old 09-16-2010, 01:46 AM
Ryan Hill
 
Default Handling of test USE flag in ebuilds

On Wed, 15 Sep 2010 19:02:00 +0200
Thomas Sachau <tommy@gentoo.org> 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.

Well, it does indicate the presence of optional dependencies.

I've always thought the test USE flag being forced by FEATURES=test was
messed up. Why can't it be controlled package-by-package, with FEATURES=test
just enabling USE=test by default?


--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgets you and me cling to the outside of the earth
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 09-16-2010, 02:01 AM
Samuli Suominen
 
Default 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.
 
Old 09-16-2010, 08:42 PM
Thomas Sachau
 
Default Handling of test USE flag in ebuilds

Am 16.09.2010 03:46, schrieb Ryan Hill:
> On Wed, 15 Sep 2010 19:02:00 +0200
> Thomas Sachau <tommy@gentoo.org> 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.
>
> Well, it does indicate the presence of optional dependencies.
>
> I've always thought the test USE flag being forced by FEATURES=test was
> messed up. Why can't it be controlled package-by-package, with FEATURES=test
> just enabling USE=test by default?
>
>

Controling the test USE flag alone without the test FEATURE is useless, since it wont run the
src_test phase. And being able to disable the test USE flag with FEATURES=test will result in
missing deps or build-system args. Can you tell me any reason, why you want to expose and control
the test USE flag independently of FEATURES=test?

--
Thomas Sachau

Gentoo Linux Developer
 
Old 09-16-2010, 08:47 PM
Thomas Sachau
 
Default 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
 
Old 09-17-2010, 03:37 AM
Ryan Hill
 
Default Handling of test USE flag in ebuilds

On Thu, 16 Sep 2010 22:42:02 +0200
Thomas Sachau <tommy@gentoo.org> wrote:

> Controling the test USE flag alone without the test FEATURE is useless, since it wont run the
> src_test phase.

...then don't do that? :P

> And being able to disable the test USE flag with FEATURES=test will result in
> missing deps or build-system args.

Add something like this to the beginning of the default src_test:

hasq test $USE || return 0

I'm sure there's a reason it won't work I'm not thinking of, but that's
the jist of the idea.

> Can you tell me any reason, why you want to expose and control
> the test USE flag independently of FEATURES=test?

So it can be controlled on a per-package basis? Circular dependencies,
unwanted dependencies, excessive testsuites, perpetually failing testsuites
that no one bothers to fix... You can mask the flag but it's inconsistant
and unintuitive. FWIW I currently have 22 packages that have the test flag
masked in package.use.mask, and probably a dozen more I just haven't gotten
around to masking.

In any case, this is straying off topic. I believe the current policy is
this: if your package's test suite requires extra dependencies, add a test
USE flag and make them conditional on that. I don't think there's any reason
it should change.


--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgets you and me cling to the outside of the earth
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 

Thread Tools




All times are GMT. The time now is 06:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org