Re: [gentoo-user] Re: What's up with the hardened USE flag?
Neil Bothwick schrieb am 05.07.2011 00:36: On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote: Why not? I see no downside to it but I'm willing to be educated. Imagine this: A package is built by default with Gtk as well as with Qt support. There is no USE flag which would omit building with one of those. Then, the ebuild developer introduces those USE flags. --changed-use will not catch this, so you will continue having both Gtk and Qt support in the package, even though you're interested only in one of them (Gnome vs KDE user, for example). Or, imagine another scenario. A package offers multithreading support, resulting in a huge speed-up on machines with more than one core or CPU. But the ebuild configures and builds the package without multithreading, and there's no USE flag. When the ebuild dev puts a USE flag in there (and probably turns it on by default), --changed-use will also not catch this, because it's not a USE flag that changed, but instead a new one that wasn't there before. So you will continue running the package in its slow built, missing out on the big performance gain. changed-use also acts on added/removed flags, it just doesn't recompile when the added/removed flag is not in use. So if my KDE system has -gtk to use your first example, you are right in that adding a gtk USE flag will not rebuild it until the next update and my program will continue to work as it did. However, adding an enabled multithreading USE flag as your second example will force a rebuild. It seems that the trade off here is that I have may have cruft that was previously compulsory but is now optional for a couple of weeks, but I won't have to rebuild libreoffice or xulrunner every time a dev tweaks a USE flag that doesn't affect me. That seems a reasonable trade to me, but I still have an open mind. The first scenario from Nikos seems valid but the second one with the per default enabled USE flag will trigger a rebuild as --changed-use only avoid rebuilds for disabled USE flags which are added or removed. I personally can only think of another issue. There may be a completely new use flag which you might want to enable. With --changed-use the changes wont show up in the depgraph and you are not aware of the new feature. You will only get them later when there is a version/revision bump. These are all minor things and as you said it is a reasonable trade for you to avoid useless rebuilds. Using --newuse instead of --changed-use is just my personal preference. Many systems are idling around most of the time, with --newuse they have to do something :) -- Regards, Daniel signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: What's up with the hardened USE flag?
On 07/05/2011 12:23 AM, Neil Bothwick wrote: On Mon, 4 Jul 2011 16:57:55 +0200, Daniel Pielmeier wrote: use --changed-use to avoid a rebuild instead of --new-use like Neil suggested. This only works if you *permanently* switch to --changed-use, otherwise you'll just postpone things to next time you use --new-use. I haven't used --new-use for years. What's the point of rebuilding packages just because irrelevant USE flags have changed? I know I am not a fan of --changed-use myself Why not? I see no downside to it but I'm willing to be educated. Imagine this: A package is built by default with Gtk as well as with Qt support. There is no USE flag which would omit building with one of those. Then, the ebuild developer introduces those USE flags. --changed-use will not catch this, so you will continue having both Gtk and Qt support in the package, even though you're interested only in one of them (Gnome vs KDE user, for example). Or, imagine another scenario. A package offers multithreading support, resulting in a huge speed-up on machines with more than one core or CPU. But the ebuild configures and builds the package without multithreading, and there's no USE flag. When the ebuild dev puts a USE flag in there (and probably turns it on by default), --changed-use will also not catch this, because it's not a USE flag that changed, but instead a new one that wasn't there before. So you will continue running the package in its slow built, missing out on the big performance gain. I guess this is why people don't use --changed-use. It won't catch cases like the above.
Re: [gentoo-user] Re: What's up with the hardened USE flag?
On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote: Why not? I see no downside to it but I'm willing to be educated. Imagine this: A package is built by default with Gtk as well as with Qt support. There is no USE flag which would omit building with one of those. Then, the ebuild developer introduces those USE flags. --changed-use will not catch this, so you will continue having both Gtk and Qt support in the package, even though you're interested only in one of them (Gnome vs KDE user, for example). Or, imagine another scenario. A package offers multithreading support, resulting in a huge speed-up on machines with more than one core or CPU. But the ebuild configures and builds the package without multithreading, and there's no USE flag. When the ebuild dev puts a USE flag in there (and probably turns it on by default), --changed-use will also not catch this, because it's not a USE flag that changed, but instead a new one that wasn't there before. So you will continue running the package in its slow built, missing out on the big performance gain. changed-use also acts on added/removed flags, it just doesn't recompile when the added/removed flag is not in use. So if my KDE system has -gtk to use your first example, you are right in that adding a gtk USE flag will not rebuild it until the next update and my program will continue to work as it did. However, adding an enabled multithreading USE flag as your second example will force a rebuild. It seems that the trade off here is that I have may have cruft that was previously compulsory but is now optional for a couple of weeks, but I won't have to rebuild libreoffice or xulrunner every time a dev tweaks a USE flag that doesn't affect me. That seems a reasonable trade to me, but I still have an open mind. -- Neil Bothwick Top Oxymorons Number 2: Exact estimate signature.asc Description: PGP signature
