1 |
> > USE=live could perfectly make sense, if it is equipped with |
2 |
> > the obvious meaning: |
3 |
> |
4 |
> Well, it seems to me that you're trying to shoehorn a USE flag into |
5 |
> a role that's intended to be filled by package sets. |
6 |
|
7 |
Maybe there is a misunderstanding: I am mainly suggesting the "live" |
8 |
USE flag to allow the user to decide in a uniform manner (and on a |
9 |
per-package basis) whether new sources shell be fetched regularly |
10 |
before the rebuild (that's why I said that my suggestion is |
11 |
slightly OT). |
12 |
|
13 |
There is no way to do this by package sets. |
14 |
|
15 |
But *if* a "live" USE flag would be uniformly used for that purpose, |
16 |
it would have also the "side effect" that you can read from IUSE |
17 |
whether it is a live package, i.e. there is no need to put this |
18 |
information additionally into the RESTRICT variable. |
19 |
|
20 |
> The idea is |
21 |
> that instead of settings USE flags in package.use, you'd define a |
22 |
> package set containing the specific packages that you want rebuilt. |
23 |
|
24 |
I guess this is part of the misunderstanding: |
25 |
I do not care so much whether @emerge-ebuild would select all packages |
26 |
with "live" in its IUSE or only those for which the "live" flag is |
27 |
actually set (from your reply I understand that you would consider |
28 |
the latter as an inappropriate use; I do not protest. Anyway, even the |
29 |
*possibility* to do this even if it is not implemented - might be |
30 |
considered as an additional feature of USE over RESTRICT). |
31 |
However to repeat: |
32 |
The main point in introducing the "live" USE flag should be IMHO to |
33 |
let the user decide whether the sources should be fetched. The fact |
34 |
that IUSE then marks live ebuilds in the way which you wanted is an |
35 |
additional side effect. |
36 |
|
37 |
Regards |
38 |
Martin |