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 03-17-2012, 06:33 PM
Matt Turner
 
Default Change USE flags when compiling with FEATURES=test

So you run set FEATURES=test to run a package's test suite during
keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
that package with USE=-test.

Can't we avoid this somehow? I presume in the vast majority of cases
emerging with FEATURES/USE=test doesn't actually affect what's
installed.

I'd guess we'd need to be able to remove 'test' from the set of IUSE
and have a new helper function to check if 'test' is in FEATURES?

Matt
 
Old 03-17-2012, 06:40 PM
Ciaran McCreesh
 
Default Change USE flags when compiling with FEATURES=test

On Sat, 17 Mar 2012 15:33:42 -0400
Matt Turner <mattst88@gentoo.org> wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.
>
> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

If you want that, USE_EXPAND_IGNORE_CHANGES, like USE_EXPAND_HIDDEN,
would be cleaner. 'test' is already too special.

--
Ciaran McCreesh
 
Old 03-17-2012, 06:43 PM
Kent Fredric
 
Default Change USE flags when compiling with FEATURES=test

On 18 March 2012 08:33, Matt Turner <mattst88@gentoo.org> wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.

Not so, there are a lot of things where USE="test" pulls in extra
dependencies, dev-perl/* is rife with them.

And I've seen some things where USE=test changes behaviour of the
compile phase sufficient that enabling USE=test *could* change the
code compiled as well.

But I think I see where you're comming from.

I just can't see a reasonable cover-all approach that wouldn't really
be a large nasty package-manager specific hack.

> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

And besides, I'll reinstall a package if so much as the MD5 changes
due to somebody adding keywording for an arch I don't use

I think what would be more practical is a sane way to enable
FEATURES="" on a per-package level like USE flags in portage, then you
could enable FEATURES="test" for that one package and it would always
build that package with USE="test"

Paludis does this already via an extended use.conf syntax:

=dev-foo/bar-1.2 flag -otherflag BUILD_OPTIONS: optional_tests
LINGUAS: en

Perhaps portage does this already and I'm hiding under a rock, but I
haven't seen it, and I've just cheated the system with

linguas_en

and other similar manual USE_EXPAND tricks in my package.use

--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
 
Old 03-17-2012, 06:45 PM
Richard Yao
 
Default Change USE flags when compiling with FEATURES=test

On 03/17/12 15:43, Kent Fredric wrote:
> On 18 March 2012 08:33, Matt Turner <mattst88@gentoo.org> wrote:
>> So you run set FEATURES=test to run a package's test suite during
>> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
>> that package with USE=-test.
>>
>> Can't we avoid this somehow? I presume in the vast majority of cases
>> emerging with FEATURES/USE=test doesn't actually affect what's
>> installed.
>
> Not so, there are a lot of things where USE="test" pulls in extra
> dependencies, dev-perl/* is rife with them.
>
> And I've seen some things where USE=test changes behaviour of the
> compile phase sufficient that enabling USE=test *could* change the
> code compiled as well.

To expand on this, I know that sys-devel/gcc will save a report of the
make check results to the filesystem when FEATURES=test is enabled.
 
Old 03-17-2012, 06:51 PM
Alexandre Rostovtsev
 
Default Change USE flags when compiling with FEATURES=test

On Sat, 2012-03-17 at 15:33 -0400, Matt Turner wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.
>
> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

Typically "test" is added to IUSE only when building and/or running the
test suite requires specifying additional dependencies. So if we remove
"test" from IUSE, we would need to allow DEPEND to have FEATURES-based
conditionals. Which would probably mean a new EAPI.

I think the easier solution is to modify portage to ignore changes in
the "test" USE flag when doing "emerge --newuse".

-Alexandre.
 
Old 03-17-2012, 06:58 PM
Zac Medico
 
Default Change USE flags when compiling with FEATURES=test

On 03/17/2012 12:51 PM, Alexandre Rostovtsev wrote:
> I think the easier solution is to modify portage to ignore changes in
> the "test" USE flag when doing "emerge --newuse".

Yes, that's part of the plan [1] discussed in bug #373209.

[1] https://bugs.gentoo.org/show_bug.cgi?id=373209#c3
--
Thanks,
Zac
 
Old 03-18-2012, 06:18 AM
Duncan
 
Default Change USE flags when compiling with FEATURES=test

Kent Fredric posted on Sun, 18 Mar 2012 08:43:55 +1300 as excerpted:

> I think what would be more practical is a sane way to enable FEATURES=""
> on a per-package level like USE flags in portage, then you could enable
> FEATURES="test" for that one package and it would always build that
> package with USE="test"
>
> Paludis does this already via an extended use.conf syntax:

> Perhaps portage does this already and I'm hiding under a rock, but I
> haven't seen it

What's you're definition of "sane"? Does it include the
/etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files
configuration options?

I've been using (and prefer) the latter for quite some time for various
per-package settings (tho not the particular one in question here)
without an issue. The former is newer but somewhat more limited, to
make.conf style direct variable assignments, while the latter allows full
bash flexibility, which I take advantage of.

For example, the following /etc/portage/env/media-video/smplayer-0.6.9-r1
allowed me to avoid editing the ebuild directly. (IIRC it was a patch
necessary to build the package with gcc-4.6. I'm on smplayer-0.7.1 now,
but the version-specific package-path limited deployment to just that one
version.)

post_src_prepare () {
sed -i '1i#define OF(x) x' src/findsubtitles/quazip/*.h
}


See the /etc/portage/package.env and /etc/portage/env/ sections of the
portage (5) manpage for the details.

So... Does that fit your definition of "sane"? =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 03-18-2012, 06:30 PM
Zac Medico
 
Default Change USE flags when compiling with FEATURES=test

On 03/18/2012 12:18 AM, Duncan wrote:
> What's you're definition of "sane"? Does it include the
> /etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files
> configuration options?
>
> I've been using (and prefer) the latter for quite some time for various
> per-package settings (tho not the particular one in question here)
> without an issue. The former is newer but somewhat more limited, to
> make.conf style direct variable assignments, while the latter allows full
> bash flexibility, which I take advantage of.

For best results, you should use package.env for FEATURES settings,
because it's applied very early, so it will even take care of enabling
USE=test when resolving dependencies. On the other hand, bashrc settings
are applied much later, when the ebuild is being executed by bash. As a
general rule of thumb, use package.env for anything that involves
variable settings alone, and use bashrc for anything that must be
executed by bash.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 11:48 PM.

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