| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 25/09/12 12:25 PM, Ciaran McCreesh wrote: |
| 5 |
> On Tue, 25 Sep 2012 12:19:21 -0400 Ian Stakenvicius |
| 6 |
> <axs@g.o> wrote: |
| 7 |
>>> a) How do we provide a good user interface for it? It took an |
| 8 |
>>> awful lot of experimenting to get the exheres-0 suggestions |
| 9 |
>>> user interface to be good, and it requires quite a bit more |
| 10 |
>>> information from the package side than this proposal is |
| 11 |
>>> providing. We want to avoid a REQUIRED_USE here... |
| 12 |
> |
| 13 |
>> Standard USE flag interface. This doesn't need anything special. |
| 14 |
>> Why will a user care if the flag doesn't trigger a package |
| 15 |
>> rebuild? |
| 16 |
> |
| 17 |
> One of the big selling points of suggestions is displaying them to |
| 18 |
> the user in a useful way (i.e. not via a bunch of einfo messages). |
| 19 |
> If you're not planning to allow for that, then you're losing a |
| 20 |
> primary benefit. |
| 21 |
> |
| 22 |
|
| 23 |
Must've missed that. I don't much care about showing things about |
| 24 |
optional program interation to users on emerge. In fact I see that as |
| 25 |
being pretty well useless. Use flag descriptions via metadata.xml , |
| 26 |
though, are *MUCH* more useful and imo suited entirely to this. |
| 27 |
|
| 28 |
(so again, standard use flag interface :) |
| 29 |
|
| 30 |
|
| 31 |
>>> b) How is consistency checking to be done? Related, what |
| 32 |
>>> happens when a runtime switch introduces a dependency that then |
| 33 |
>>> requires a non-runtime rebuild of the original package? |
| 34 |
> |
| 35 |
>> flag needs to be dropped from IUSE_RUNTIME, so the rebuild would |
| 36 |
>> occur. |
| 37 |
> |
| 38 |
> Uh, you're requiring ebuilds to ensure consistency of every |
| 39 |
> possible configuration of the entire tree? |
| 40 |
|
| 41 |
No, only on a per-atom basis. Maybe I didn't understand what it is |
| 42 |
you're referring to here. Could you elaborate the issue you are |
| 43 |
forseeing with a verbose example? |
| 44 |
|
| 45 |
|
| 46 |
|
| 47 |
>>> c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( |
| 48 |
>>>> =cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is |
| 49 |
>>> installed and flag is off? From experience, quite a few places |
| 50 |
>>> where you'd want to use suggestions will break if their |
| 51 |
>>> suggested package is installed but doesn't meet version or use |
| 52 |
>>> requirements. |
| 53 |
> |
| 54 |
>> Use flag deps are dealt with identically to the way they are now. |
| 55 |
>> the only difference , again, is that the package doesn't get |
| 56 |
>> re-emerged. The VDB would still update imo as if the package did |
| 57 |
>> get re-emerged (ie: USE and RDEPEND would update), to handle the |
| 58 |
>> use flag change info in metadata but from what I can tell nothing |
| 59 |
>> else would need to be touched. |
| 60 |
> |
| 61 |
> So such packages would just break at runtime? |
| 62 |
> |
| 63 |
|
| 64 |
Again, you lost me. The package is still added to the emerge list |
| 65 |
same as always, and its dependencies (based on USE) are evaluated same |
| 66 |
as always. The package just doesn't REBUILD, because a rebuild would |
| 67 |
not result in any change-on-disk. |
| 68 |
|
| 69 |
If there are conflicts in the emerge list then these would be reported |
| 70 |
just like if IUSE_RUNTIME wasn't used at all...?? |
| 71 |
|
| 72 |
|
| 73 |
-----BEGIN PGP SIGNATURE----- |
| 74 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 75 |
|
| 76 |
iF4EAREIAAYFAlBh3nIACgkQ2ugaI38ACPCilwD9HbOgxa99t0pRPI/wt4f6zvFT |
| 77 |
Lsjc140u+i15NIcatM8A/1tTC6LLIIFTBma13I0au9rdFRC9C5+oqTPI3bGpf3bx |
| 78 |
=0ebw |
| 79 |
-----END PGP SIGNATURE----- |
Archives