| 1 |
On Fri, 15 Jan 2016 00:00:02 +0100 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> >>>>> On Thu, 14 Jan 2016, Michał Górny wrote: |
| 5 |
> |
| 6 |
> > On Thu, 14 Jan 2016 07:28:43 -0500 |
| 7 |
> > Rich Freeman <rich0@g.o> wrote: |
| 8 |
> |
| 9 |
> >> One way to do this (and I'm certainly open to others) is a |
| 10 |
> >> Display-If-Installable header which takes a keyword string and an |
| 11 |
> >> atom (typically a specific PV). The package manager would |
| 12 |
> >> determine if a package with that keyword string and PV would be |
| 13 |
> >> accepted or not based on the user's configuration, and if so |
| 14 |
> >> display the news. |
| 15 |
> |
| 16 |
> > Based on your idea, this is how I'd do it: |
| 17 |
> |
| 18 |
> > 1. 'Display-If-Visible' that enables news items if given atom is |
| 19 |
> > visible for PM (i.e. in repo, with right keywords and not masked). |
| 20 |
> > I would avoid using 'Installable' as that could get confusing wrt |
| 21 |
> > conflicts and so on. |
| 22 |
> |
| 23 |
> I had omitted the Display-If-Visible header (which has been discussed |
| 24 |
> since 2007 at least) deliberately, because we want to get format 2.0 |
| 25 |
> done in a timely manner. |
| 26 |
|
| 27 |
That doesn't really make sense to me. There is no real urgency in |
| 28 |
getting the new format right now, and omitting the most important issue |
| 29 |
is not really the solution here. |
| 30 |
|
| 31 |
> The problem with any visibility filtering is that visibility depends |
| 32 |
> on user configuration [1], and I don't know what changes in the |
| 33 |
> package manager would be necessary to make this work correctly and |
| 34 |
> efficiently. For example, how does portage's --autounmask-write option |
| 35 |
> interact with it? |
| 36 |
|
| 37 |
Leave solving this to Portage developers. Autounmasking is not |
| 38 |
something you do often on stable systems, and we have better QA to |
| 39 |
avoid issues that could require it. |
| 40 |
|
| 41 |
What's most important right now is to have Portage process news items |
| 42 |
after 'emerge --sync' (or any other emerge operation), check visibility |
| 43 |
of packages (with current configuration) and enable news items that |
| 44 |
apply. |
| 45 |
|
| 46 |
We could also process changed news files on emerge start, and warn |
| 47 |
verbosely that new news items start applying. |
| 48 |
|
| 49 |
> [1] https://bugs.gentoo.org/show_bug.cgi?id=290038#c9 |
| 50 |
|
| 51 |
-- |
| 52 |
Best regards, |
| 53 |
Michał Górny |
| 54 |
<http://dev.gentoo.org/~mgorny/> |
Archives