Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 81405 - kdeenablefinal should NOT be a USE flag! or some other solution needs to be made so the kde ebuilds don't show up with --newuse
Summary: kdeenablefinal should NOT be a USE flag! or some other solution needs to be m...
Status: VERIFIED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 136991 158008 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-02-09 12:34 UTC by David Grant
Modified: 2010-12-20 05:09 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Grant 2005-02-09 12:34:38 UTC
kdeenablefinal should NOT be a USE flag! It does not affect the package in runtime, only during compile time. Should be put in /etc/make.conf and kept out of USE.

If I change it and run emerge -uvp --newuse world I get all these kde packages. That's stupid, because there would be no reason to reemerge it, kdeenablefinal is just a build-time thing and there is no difference in the final binaries.

USE flags like +real and +ipv6 and +3dnow and +truetype actually change affect a packages binaries, and it is useful to see what packages require rebuilding with the --newuse option.
Comment 1 Carsten Lohrke (RETIRED) gentoo-dev 2005-02-09 13:59:18 UTC
>If I change it and run emerge -uvp --newuse world I get all these kde packages. That's stupid, because there would be no reason to reemerge it, kdeenablefinal is just a build-time thing and there is no difference in the final binaries.

That's how it is supposed to be, when you run a world update. If you want to change it only for distinct packages, add them to package.use (man portage), instead changing the flag globally or don't run emerge world.
Comment 2 David Grant 2005-02-09 15:56:47 UTC
Yes I realized that.

But kdeenablefinal does not affect run time so it should not be a USE flag.

There are a few other USE flags which affect build-time only, such as the "build" use flag, but I repeat: kdeenablefinal should be in /etc/make.conf or somewhere else in /etc, besides USE=

This will retain the usefulness to --newuse, in telling people which packages could be rebuilt as a result of changed USE flag settings.
Comment 3 Carsten Lohrke (RETIRED) gentoo-dev 2005-02-09 17:06:21 UTC
I see your point David, but you're facing this, because 
- the flag is new
- you insist to enable it globally while doing emerge world

If we add every packages very own flags as environment variables (to make.conf), this will become confusing.


herd, what do you think?
Comment 4 David Grant 2005-02-09 19:03:20 UTC
Thanks Carsten for you input, it is insightful. Let me just tell my story to get it straight.

-I enabled kdeenablefinal to emerge k3b.
-My thinking was "I'll enable USE flag globally, because I WANT it to be enabled for all future kde packages I upgrade."
-Every night I run an emerge -uvp --newuse world and pipe the output to an e-mail to myself.
-When I got it in the morning I had a mess. emerge wanted to re-emerge every single KDE application, NOT because they needed re-emerging to do some new functionality created by a USE flag change, but because of the kdeenablefinal
-This has not happened to me with any other USE flag before. All other USE flag changes warranted a re-build of some package.

Yes, this is a small, niggly thing. But preventing these kinds of annoyances will be what makes Gentoo even greater than it already is. I'm not sure how it will be implemented.
Comment 5 Dan Armak (RETIRED) gentoo-dev 2005-02-11 08:30:35 UTC
I agree that this is a problem. I just don't see a good solution.

If we used env. variables (set in make.conf or in emerge's env), that would
have far less user visibility than USE flags. Also, if in the future we decide
to make this on by default, some archs might want to make it off by default in
their profiles (or vice versa). Asking archs to introduce a custom variable
into their make.defaults is bad. 

Finally, a USE flag gets recorded in the installed packages database and in
emerge info, so if enable-final does cause trouble one day it'll be a lot
easier to spot in bugreports.

In any case, the damage is now done. If we removed the use flag, it'd cause
everyone who has emerged kde while it existed to see it in --newuse _again_.
We should be more careful in the future.

Perhaps the best way to handle this would have been to only add the use flag
to 3.4 ebuilds. Then, outside a small population of beta testers, people would
see the ebuilds with the use flag from the beginning.

But I don't see what we can about this now.
Comment 6 Jan Kundrát (RETIRED) gentoo-dev 2005-02-15 13:09:55 UTC
Well, you can patch portage to include support for USE flags that doesn't require recompilation ;-). But it won't help in this case, only in future...
Comment 7 Fela Winkelmolen 2005-04-06 09:07:55 UTC
I had this problem too, and it's very annoying. I'm not sure I should submit a feature request to get this problem solved in future versions of portage or if this bug report is enough.

Another option i think shouldn't affect --newuse is kdexdeltas.
Comment 8 Carsten Lohrke (RETIRED) gentoo-dev 2005-04-07 11:57:26 UTC
This is nothing the kde herd can fix and will also be a more general having deltup (or maybe even --new-compilerflags in some distant future in mind), so I'm forwarding...

There are several ways to solve the problem. The most simple way would be to add  a newuse.exclude list, which won't work, if a use flag would be used in different ebuilds with and without --newuse in mind. 'IUSE= && A(nother)USE=' or a use flag prefix to indicate the ebuild/use flag combination should not be affected by --newuse would be possible, too. The downside is here, that it'd be another thing to be added in every ebuild/eclass (in the kde case in the eclass only). Prefixes would also conflict with the use flag grouping ideas floating around. IUSE="%+
Comment 9 Carsten Lohrke (RETIRED) gentoo-dev 2005-04-07 11:57:26 UTC
This is nothing the kde herd can fix and will also be a more general having deltup (or maybe even --new-compilerflags in some distant future in mind), so I'm forwarding...

There are several ways to solve the problem. The most simple way would be to add  a newuse.exclude list, which won't work, if a use flag would be used in different ebuilds with and without --newuse in mind. 'IUSE= && A(nother)USE=' or a use flag prefix to indicate the ebuild/use flag combination should not be affected by --newuse would be possible, too. The downside is here, that it'd be another thing to be added in every ebuild/eclass (in the kde case in the eclass only). Prefixes would also conflict with the use flag grouping ideas floating around. IUSE="%+§$~someuseflag" looks interesting, though. ;)


As a workaround, modifying /var/db/pkg/*CATEGORY*/*EBUILD*/USE should do it, but don't start jabbing your fingers into my ribs, if you break something. ;)
Comment 10 SpanKY gentoo-dev 2005-04-07 13:27:26 UTC
sounds like a whole lot of crap complexity for very little gain
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2005-04-07 13:30:03 UTC
I'm inclined to agree with Mike
Comment 12 Carsten Lohrke (RETIRED) gentoo-dev 2005-04-07 13:43:35 UTC
SpanKY: Technical seen I agree and can live with it, when our portage developers say plain "no". On the other hand I can understand every user who doesn't feel fine to rebuild stuff for no better reason, than a obiously still insufficient software mangement system. ;) Your comment is valid for probably 60% of all the use flags btw...
Comment 13 SpanKY gentoo-dev 2005-04-07 15:36:30 UTC
did you pull the '60%' figure out of your 3rd eye or is that a real figure ?

it's my impression that very few USE flags fall into the 'does not affect installed package' category and thus this kind of feature support is worthless ...

if however we have a significant % of USE flags which could be used here, then the feature might be worth it
Comment 14 Carsten Lohrke (RETIRED) gentoo-dev 2005-04-07 16:14:58 UTC
>did you pull the '60%' figure out of your 3rd eye or is that a real figure ?

I could live with less of them. But that does not relate to this thread and of course it's not "a real figure".

>if however we have a significant % of USE flags which could be used here, then the feature might be worth it

Supposed GLEP 25 functionality will be enabled via some use flag (and I'm don't think it can/should be done globally via another FEATURE keyword), it will affect the whole tree.
Comment 15 David Grant 2005-04-07 17:40:41 UTC
comment #12 raises an interesting point. There are very few USE flags which behave like this one. ie. there are not many USE flags which affect only build-time behaviour. Which again, makes me wonder why it was ever made a USE flag. Should have been made a setting in /etc/make.conf (or /etc/kde.conf for all I care).

If we applied the logic used by whoever made kdeenablefinal a USE flag, we would have USE flags for athlon, mmx, sse, O2, O3, blah, blah...
Comment 16 SpanKY gentoo-dev 2005-04-07 18:02:01 UTC
actually we have USE flags for mmx, sse, 3dnow, etc...

and other than a USE flag, there arent any good choices for how to add the feature to the ebuild ... and env var is really not appropriate

also, i'm not quite sure what your definition of what a USE flag is ... really it's just something that enables/disables features in packages ... we've never defined it as something that ONLY affects the resulting package
Comment 17 David Grant 2005-04-07 18:16:05 UTC
Oh yeah, good point. I wonder why mmx and sse aren't in CFLAGS in make.conf. And why O2 or O3 isn't a USE flag.
Comment 18 SpanKY gentoo-dev 2005-04-07 18:23:46 UTC
because sometimes enabling support for processor specific features requires more than just using CFLAGS
Comment 19 Jason Stubbs (RETIRED) gentoo-dev 2005-04-08 20:44:34 UTC
kdeenablefinal will cause different binaries. It may not add or remove features, but the resulting binaries will be different as gcc will reorder things and optimize other things on a much bigger file.

Personally, I don't see this as a bug. --newuse is doing what it is meant to do. If kdeenablefinal is somehow made special and --newuse doesn't look at it, what are the people that *want* to recompile those packages to do?
Comment 20 David Grant 2005-04-08 21:38:20 UTC
Jason, I never thought of that. But does having one big cpp file really affect the final binary?

I agree that newuse is doing what it is supposed to do. I don't think I specifically said the bug is in newuse though. I think the best solution is just to add a newuse.mask in /etc/portage which can mask out USE changes that I don't care about.
Comment 21 Dan Armak (RETIRED) gentoo-dev 2005-04-09 10:18:11 UTC
enable-final allows the compiler to optimize the binary more, because it looks
at all the source in one stage. But the actual performance difference due to
this is considered too small to reliably measure. The real reason to use this
is much faster compiles (which might go away, at least partly, with precompiled
headers).

As for kdexdeltas, there's no difference whatsoever in the installed packages.

Use flags do have significant advantages: they are highly visible to the user
in emerge -pv output and have standard editors (ufed), descriptions in
use.conf, etc. If these two weren't use flags, most users wouldn't know about
them. Plus, we can set per-profile defaults and mask them on unwanted archs.
Mere env variables can't replace this.

So as I said before, the only (partial) solution is to try to match appearances
of these flags to new versions of ebuilds, so that --newuse doesn't come into
play.
Comment 22 David Grant 2005-04-09 11:16:40 UTC
"So as I said before, the only (partial) solution is to try to match appearances
of these flags to new versions of ebuilds, so that --newuse doesn't come into
play."

I agree. This should be mandated somehow for the future.
Comment 23 SpanKY gentoo-dev 2005-04-09 11:49:55 UTC
and again, the 'gain' here isnt worth the additional complexity imho
Comment 24 David Grant 2005-04-09 12:10:42 UTC
see comment #21 for possible resolution
Comment 25 LXj 2006-06-03 07:02:20 UTC
> The author told me that needed plugins for a minimal kxdocker
> installation are:
> kde-misc/kxdocker-resources-1.0.0
> kde-misc/kxdocker-trayiconlogger-1.0.0
> kde-misc/kxdocker-dcop-1.0.0
> kde-misc/kxdocker-thememanager-1.0.0
> kde-misc/kxdocker-configurator-1.0.0
> kde-misc/kxdocker-taskmanager-1.0.0
> kde-misc/kxdocker-mountmanager-1.0.0

Maybe we could cut this list too? As for me I unmerged mountmanager just after installing kxdocker.
Comment 26 David Grant 2006-06-03 16:32:02 UTC
lxj, did you reply to the wrong bug?
Comment 27 LXj 2006-06-04 03:15:49 UTC
Crap. Bugzilla screwed my comment again.

What I really wanted to say: 
Maybe kdeenablefinal and kdexdeltas should be FEATURES, not USE flags?
Comment 28 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-06-04 05:57:17 UTC
(In reply to comment #26)
> Crap. Bugzilla screwed my comment again.
> 
> What I really wanted to say: 
> Maybe kdeenablefinal and kdexdeltas should be FEATURES, not USE flags?
> 

The day we have package specific FEATURES is the day I quit Gentoo ;)

USE flags are the only thing valid to mess with a DEPEND string, thus everything is a USE flag because modified DEPENDS based on anything else thats not static causes cache invalidation and is not correct.

You want per-package env.  I am not sure when that will be implemented officiallly, it is possible now via /etc/portage/bashrc.
Comment 29 LXj 2006-06-04 07:56:37 UTC
> The day we have package specific FEATURES is the day I quit Gentoo ;)

It's not package specific, all packages in kde-base/ depend on it. It's eclass-specific though

> USE flags are the only thing valid to mess with a DEPEND string, thus
> everything is a USE flag because modified DEPENDS based on anything else thats
> not static causes cache invalidation and is not correct.

kdeenablefinal doesn't affect dependencies at all

kdexdelta should not affect it too -- as ccache, confcache depend specific packages to work but don't affect dependecies

> You want per-package env.  

All I want is kdexdeltas implementation not to be ugly. BTW nobody cares about kdexdeltas anymore, so it doesn't work at all for kde >3.5.0 (yes, there is appropriate bug in BugZilla)
Comment 30 Matteo Azzali (RETIRED) gentoo-dev 2006-06-07 05:18:15 UTC
Well, I can swear about having the moon, but I doubt I'll have.

Please stop commenting this bugreport, there's no way you can have 
kdeenablefinal and kdexdelta as FEATURES unless you become a developer
and get to be both base system and kde leader developer..... sorry.

Until then, please, just use ufed or manually add these flags to your
/etc/make.conf (result will be a lot similar).

KDE team is actually busy for lots of other reports and any further
comment on this closed report will just subtract time for the open ones.
Comment 31 David Grant 2006-06-07 09:39:10 UTC
A much simpler solution is just to modify the emerge -N to look at some use flag mask.
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-06-16 08:24:10 UTC
*** Bug 136991 has been marked as a duplicate of this bug. ***
Comment 33 Scott Jubenville 2006-06-16 08:48:42 UTC
A work around is to modify the USE files for all the installed ebuilds.

find /var/db/pkg -name USE | xargs sed -i "s/kdeenablefinal//g"
(Suggested by Zac Medico)

This should be harmless and achieve the desired results once kdeenablefinal is removed from the USE= in /etc/make.conf. (No re-compilation will occur)
Comment 34 Jakub Moc (RETIRED) gentoo-dev 2006-12-13 03:40:12 UTC
*** Bug 158008 has been marked as a duplicate of this bug. ***
Comment 35 Erik 2010-12-19 09:19:52 UTC
(In reply to comment #19)
> kdeenablefinal will cause different binaries. It may not add or remove
> features, but the resulting binaries will be different as gcc will reorder
> things and optimize other things on a much bigger file.

That is correct! Not only will kdeenablefinal allow global optimizations by having all the code in a single compilation unit. Applications can even help optimize things further in kdeenablefinal mode. For example, some functions can be declared to be inlined when kdeenablefinal is set. Then no body will be generated for them. A macro like this can be used for that purpose:

#ifdef KDE_USE_FINAL
#define final_inline inline
#else
#define final_inline
#endif