| 1 |
>>>>> On Sat, 16 Jan 2016, Michał Górny wrote: |
| 2 |
|
| 3 |
> That doesn't really make sense to me. There is no real urgency in |
| 4 |
> getting the new format right now, and omitting the most important |
| 5 |
> issue is not really the solution here. |
| 6 |
|
| 7 |
The idea was to introduce EAPI 5 dependencies for the |
| 8 |
Display-If-Installed header. Anything else is an added bonus at this |
| 9 |
stage, and can be included if it is trivial to implement. |
| 10 |
|
| 11 |
Nothing prevents us from creating a format 2.1 or 3.0 later for any |
| 12 |
features that will take more time. Or, if we are thinking in long time |
| 13 |
scales, we could even incorporate the news item spec into PMS with the |
| 14 |
next EAPI (and replace the format number by the EAPI). |
| 15 |
|
| 16 |
>> The problem with any visibility filtering is that visibility |
| 17 |
>> depends on user configuration [1], and I don't know what changes in |
| 18 |
>> the package manager would be necessary to make this work correctly |
| 19 |
>> and efficiently. For example, how does portage's --autounmask-write |
| 20 |
>> option interact with it? |
| 21 |
|
| 22 |
> Leave solving this to Portage developers. Autounmasking is not |
| 23 |
> something you do often on stable systems, and we have better QA to |
| 24 |
> avoid issues that could require it. |
| 25 |
|
| 26 |
Yeah, if I wasn't sure about Display-If-Visible, then this statement |
| 27 |
would finally convince me that we should skip that feature, for the |
| 28 |
time being. That something does not happen often is no excuse for not |
| 29 |
having an implementation that can handle such rare cases. |
| 30 |
|
| 31 |
Ulrich |
Archives