On Thu, 14 Jan 2016 07:28:43 -0500 Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, Jan 12, 2016 at 1:13 PM, Ulrich Mueller <u...@gentoo.org> 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. I was going to speak about this, and you beat me up to it... > 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. ...and I think you've found a pretty good solution to the problem. However, I get lost in your wall of text and I don't really see the problems you see. Based on your idea, this is how I'd do it: 1. 'Display-If-Visible' that enables news items if given atom is visible for PM (i.e. in repo, with right keywords and not masked). I would avoid using 'Installable' as that could get confusing wrt conflicts and so on. 2. Combine that with 'Display-If-Installed' -- and we should be able to get somewhat sane behavior. For example, for foo-1.0 to -2.0 upgrade notes, we'd do: Display-if-installed: <foo-2.0 Display-if-visible: >=foo-2.0 which would basically mean that all people having old foo installed would get the item as soon as they foo-2.0 becomes visible to them. But people installing straight 2.0 without previous versions don't get the item. We could also do: Display-if-installed: foo Display-if-visible: >=foo-2.0 which would cause the item to be displayed to both people who have old foo installed and can upgrade, or installed 2.0 directly. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpHvRxx4n_iB.pgp
Description: OpenPGP digital signature
