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

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

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 );"

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.

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.

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

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

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