Re: [gentoo-dev] RFD: News item format 2.0

[Rich Freeman]

On Tue, Jan 12, 2016 at 1:13 PM, Ulrich Mueller <ulm@g.o> wrote:
>
> Therefore, we could use the opportunity to add some other features.
> So far, this includes:
>

I don't have a solution for this in mind, but I do see a problem that
could use a solution with our current approach to news in our stable
and unstable branches.

Using the current criteria we have for displaying news items it is
very hard to prepare a news item that is displayed at an appropriate
time for both stable and unstable users of a package.  Either the
unstable users don't get the news item at all, or everybody gets it at
the same time.  Then stable users end up getting confused and
eventually forgetting about the notice, only to be hit with the update
after a significant time lag (it could be a year or more in some
cases) without any advance news.

One way to do this (and I'm certainly open to others) is a
Display-If-Installable header which takes a keyword string and an atom
(typically a specific PV).  The package manager would determine if a
package with that keyword string and PV would be accepted or not based
on the user's configuration, and if so display the news.  So, if the
string "~amd64 ~x86", =www-client/apache-2.4.19 were passed, users
running ~arch would generally get the message, as would a user running
stable but with <www-client/apache-2.5 in their package.keywords, but
not a user running stable with <www-client/apache-2.4.19 in their
package.keywords.  If a user already was running
www-client/apache-2.4.21 the news would not display since the package
manager wouldn't attempt to install 2.4.19 if it showed up in the tree
(I'm open to argument as to whether it should show up if 2.4.19 is
already installed as there are pros and cons here).  Note that this is
all hypothetical and the news should be triggered even if 2.4.19 isn't
in the tree yet, or if it is in the tree with a different set of
keywords.

Now, this would still potentially require putting the same news item
into the tree multiple times to trigger it for the unstable/stable
users, but the key would be that the right users get the message when
this happens.  Since the details of the news and what PV it applies to
might change between unstable/stable this is probably appropriate
anyway.  Likewise if three archs are going stable now and two more a
year from now the news could be re-triggered just for those archs.

The main downside to this I see is complexity - you can't just set up
one news item and have it do the right thing.  The main advantage I
see to this is correctness - it handles both the case where keywords
are set in make.conf and package.keywords, because it provides enough
of a hint to the package manager about what is about to be introduced
into the tree.

There could easily be a better solution for this.  However, I think it
is a problem worth solving.

-- 
Rich