On Tue, Apr 07, 2015 at 12:37:04AM +0300, Andrew Savchenko wrote:
> On Mon, 6 Apr 2015 09:59:22 +0200 Michał Górny wrote:
> [...]
> > > Hmm, that's a hard question. I tried to consider this issues from a
> > > point of view of a user of such arch. If package is not used or
> > > user may delete it and its deps without much harm, it doesn't affect
> > > user at all. If it is used and needed, then in case of:
> > > 
> > > - one package with removed stable keyword a user have to add to
> > > package.keywords only a single package, though it might be
> > > difficult to locate such package, because portage deptree failure
> > > events may be really obscure sometimes;
> > > 
> > > - all subtree of stable keywords is removed; then user have to
> > > add all these packages to package.keywords, portage messages should
> > > be clear here (but one never knows), though manual keywording of
> > > hundred of packages will be irritating at best (even using "cat/*"
> > > masks). So if number of affected installed packages is large, users
> > > will likely move to ~arch all their setup.
> > > 
> > > So from user's perspective stable deptree broken in single point is
> > > a better solution, but(!) if portage will cleanly suggest this
> > > point.

I believe it does. If you try to emerge something that is ~ or has ~ on
one of its deps portage will tell you what you need to unmask to make
the emerge possible.

> > > 
> > > Another issue to consider: what if we have one such package that
> > > broke stable deptree, then after awhile another one and so on. In
> > > the result stable tree will got corrupted beyond repair.

At that point, I would say it is time to consider dropping the affected
arch to dev or exp.

> > > Maybe some grace period will help here? E.g. remove stable keyword
> > > from a single package, wait for 30 days (or so) for reaction from a
> > > team, and then dekeyword all reverse dependencies.

Dekeywording all reverse dependencies makes me nervous. There could be
other packages that share those reverse dependencies, so I don't think
you want to do that unless you know that no stable package on the arches
in question shares the reverse dependencies. I would rather remove the
older version of the package once the stable req has had arch teams
assigned for 90 days and there has been no update to it or stabilization
of the newer version.

William