Michał Górny <mgo...@gentoo.org> wrote: > > Repoman is not a social tool. It's a technical dep checker, and if you > start allowing exceptions to the rules
Repoman might still access use.stable.mask without having portage force it on users. The social conflict I mean is: You *want* that users do not decide for ~ARCH but instead always against enabling the USE-flag, so you make it technically very hard for them to even recognize that a decision is being made for them. The solution in the other posting with displaying ~foo (and simple unmasking) gives the user the freedom back. > Let's move this a few blocks back. So, on a regular stable system, > should portage report you every time that this new package version is > not tested and you shouldn't be using it? I did not mean that portage should report *every* time: I meant that portage report if a stable.masked USE-Flag is disabled. So you make the decision to either disable the USE-Flag for this package or to disable the stable.mask by whatever mechanism (e.g. by package.use_accept_keywords or something similar or by overriding the profile or something else). However, if package.accept_keywords does no magic on package.use, perhaps a clear indication in the output like ~foo is sufficient. (Otherwise you might not even get to such an output due to dependency hell). > If it can easily be improved, then why didn't *you* improve it yet? A lot of portage output might be improved if one is willing to spend enough time. But this is not the topic of the discussion. Please, do not build a strawman like ... > Then we can consider what to do next. ... and then thinking about 9 other tasks (of course, all must be implemented *by me*) before you are willing to discuss the issue I wanted to discuss. > The point you are missing is that we actually have stable users who > essentially want *stable* system. Those people don't want to get > testing packages unless absolutely necessary, and they'd rather wait > for Python 3 to go stable than unmask the flag for the fun of it. These users will not have PYTHON_TARGETS="python3_3", so not forcing use.stable.mask on them makes no difference. If they *should* have PYTHON_TARGETS="python3_3", either by mistake or intentional, they will see that an unstable python is pulled in, and they have to take actions. It is better that they see this "mistake" than if just their choice is tacitly undone. >> Moreover, for use.stable.mask this cannot happen on a per-package basis. > > It's called package.use.stable.mask. I was expecting that you cannot undo something in package.use.stable.mask which was set in use.stable.mask but I just tried, and you are right. >> Perhaps one can introduce a better way to unmask use.stable.mask? > > Like what? I thought about a new config-file, but after now knowing that package.use.stable.mask can be used to undo use.stable.mask, I am not so convinced whether this is really necessary. >> Do you mean by "extra flags" again those of use.package.mask? >> Then isn't this again an argument against use.package.mask at all? > > I mean stable-masked flags. So you get 2-in-1 with no clear indication > that you got an extra unmask. With the ~foo indication this would not happen. > Then the user gets to rebuild python-exec which is a tiny C executable. > Reverse dependencies are not rebuilt. I could reproduce that libreoffice and some other consuments got [r] when I marked all */python-exec as ~amd64 in package.acccept_keywords, but it did not get reemerged when I did not do this. Of course, it might be that something else is going on here, or it might even be a bug in portage.
