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.
>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.
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.
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?
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.
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.
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...
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.
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="%+
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. ;)
sounds like a whole lot of crap complexity for very little gain
I'm inclined to agree with Mike
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...
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
>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 #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...
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
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.
because sometimes enabling support for processor specific features requires more than just using CFLAGS
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?
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.
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.
"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.
and again, the 'gain' here isnt worth the additional complexity imho
see comment #21 for possible resolution
> 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.
lxj, did you reply to the wrong bug?
Crap. Bugzilla screwed my comment again. What I really wanted to say: Maybe kdeenablefinal and kdexdeltas should be FEATURES, not USE flags?
(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.
> 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)
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.
A much simpler solution is just to modify the emerge -N to look at some use flag mask.
*** Bug 136991 has been marked as a duplicate of this bug. ***
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)
*** Bug 158008 has been marked as a duplicate of this bug. ***
(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
