| 1 |
Neil Bothwick schrieb am 05.07.2011 00:36: |
| 2 |
> On Tue, 05 Jul 2011 00:47:07 +0300, Nikos Chantziaras wrote: |
| 3 |
> |
| 4 |
>>> Why not? I see no downside to it but I'm willing to be educated. |
| 5 |
>>> |
| 6 |
>> |
| 7 |
>> Imagine this: A package is built by default with Gtk as well as |
| 8 |
>> with Qt support. There is no USE flag which would omit building |
| 9 |
>> with one of those. Then, the ebuild developer introduces those |
| 10 |
>> USE flags. --changed-use will not catch this, so you will continue |
| 11 |
>> having both Gtk and Qt support in the package, even though you're |
| 12 |
>> interested only in one of them (Gnome vs KDE user, for example). |
| 13 |
>> |
| 14 |
>> Or, imagine another scenario. A package offers multithreading |
| 15 |
>> support, resulting in a huge speed-up on machines with more than |
| 16 |
>> one core or CPU. But the ebuild configures and builds the package |
| 17 |
>> without multithreading, and there's no USE flag. When the ebuild |
| 18 |
>> dev puts a USE flag in there (and probably turns it on by |
| 19 |
>> default), --changed-use will also not catch this, because it's not |
| 20 |
>> a USE flag that changed, but instead a new one that wasn't there |
| 21 |
>> before. So you will continue running the package in its slow built, |
| 22 |
>> missing out on the big performance gain. |
| 23 |
> |
| 24 |
> changed-use also acts on added/removed flags, it just doesn't |
| 25 |
> recompile when the added/removed flag is not in use. So if my KDE |
| 26 |
> system has -gtk to use your first example, you are right in that |
| 27 |
> adding a gtk USE flag will not rebuild it until the next update and |
| 28 |
> my program will continue to work as it did. However, adding an |
| 29 |
> enabled multithreading USE flag as your second example will force a |
| 30 |
> rebuild. |
| 31 |
> |
| 32 |
> It seems that the trade off here is that I have may have cruft that |
| 33 |
> was previously compulsory but is now optional for a couple of weeks, |
| 34 |
> but I won't have to rebuild libreoffice or xulrunner every time a dev |
| 35 |
> tweaks a USE flag that doesn't affect me. |
| 36 |
> |
| 37 |
> That seems a reasonable trade to me, but I still have an open mind. |
| 38 |
|
| 39 |
The first scenario from Nikos seems valid but the second one with the |
| 40 |
per default enabled USE flag will trigger a rebuild as --changed-use |
| 41 |
only avoid rebuilds for disabled USE flags which are added or removed. |
| 42 |
|
| 43 |
I personally can only think of another issue. There may be a completely |
| 44 |
new use flag which you might want to enable. With --changed-use the |
| 45 |
changes wont show up in the depgraph and you are not aware of the new |
| 46 |
feature. You will only get them later when there is a version/revision bump. |
| 47 |
|
| 48 |
|
| 49 |
These are all minor things and as you said it is a reasonable trade for |
| 50 |
you to avoid useless rebuilds. Using --newuse instead of --changed-use |
| 51 |
is just my personal preference. Many systems are idling around most of |
| 52 |
the time, with --newuse they have to do something :) |
| 53 |
|
| 54 |
-- |
| 55 |
Regards, |
| 56 |
Daniel |
Archives