Michał Górny <mgo...@gentoo.org> wrote: > >> As I understand, it tries to solve a "social" issue >> (that an ARCH user might set a USE-flag which eventually >> pulls in an ~ARCH package) on a technical level >> (by forcibly disabling the USE-flag for the user). >> Solving social problems by technical means is never a good >> idea: > > Then you don't understand it. > > The basic issue is that we couldn't stabilize a package without > stabilizing all of its optional dependencies.
Exactly: The social issue is that you have this rule fixed without any exceptions and do not want to discuss about exceptions. > There were even cases when I had to revbump a package in order to keep > 'limited' revision to stabilize and 'full' to keep testing. The social issue has to be solved and it has to be clarified when packages are allowed to have USE-flags depending on unstable packages which the user has to resolve when he wants them. > Just to be clear -- this isn't only a social issue. This is a valid QA > concern that we had no distinction between 'flags that are fine on > stable' and 'flags that are not'. If some flags work and some do not, > resulting in 'unsatisfiable dep' errors, this is technical. No. The user has to be told that he *should* not use such certain flags on a stable system. This can happen by portage reporting a message that some USE-dependency is pulling in an unstable package, but it can also happen in a different way. The use.stable.mask "solution" is to not inform the user but just decide behind his back that he cannot use the flag and enforce this decision. Instead, e.g. one can let portage report if some useflag described in use.stable.mask needs to be disabled, or one can use some "I_KNOW_WHAT_I_AM_DOING" name, or whatever. There are many ways of reporting. But forcing a decision on the user without even communicating reasonably why this decision was forced is very bad IMHO. > Answer yourself the following questions: does portage suggest removing > the flag in the case? Does portage in any way explain that a particular > dependency was pulled in due to USE flag? The output can easily be improved: It is not rocket science to list "required by category/package[FLAG]" instead of "required by category/package" or to display the relevant part of the dependency string (something similar is done already for REQUIRED_USE, so the logic probably already exists in portage). > And just in case: the proper course of action then is to *report > a bug*. And in the end, thanks to your glorified solution, we end up > with dozens or hundreds of 'CANTFIX' bugs. Yeah, it is much better to throw the users into dependency hell in which they have no clue how to find out. Certainly they will never report any bugs in this case when they can so easily solve this by just going through all dependencies and all profiles manually and understanding all details. > If you have a problem with USE flag being masked, you unmask the USE > flag. It is simple like this. Yes, the sane way to deal with use.stable.mask for the user is to undo manually everything which is set there. But is it really a good feature, if the user essentially only removes it? > I don't agree with the whole idea of unmasking flags via playing with > accept_keywords. In my opinion, it's just a terrible bug or mis-design. > It's not something that should be encouraged, or even happen. I completely agree. But the only way to unmask it otherwise is to undo use.stable.mask. Then why have use.stable.mask in the first place? Moreover, for use.stable.mask this cannot happen on a per-package basis. Perhaps one can introduce a better way to unmask use.stable.mask? > Even worse than that, people with mixed systems get extra flags even if > they don't want them. And this is an easy way to have them end up with > half of the system on testing. 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? > It's magic only because you did it wrong. No, it is magic because it makes a decision (pulling in ~amd64 or unsetting USE) without communicating appropriately with the user and even without giving him a clean possibility to decide differently. (Modifying the profile is more a hack than a clean possibility). Moreover, once the thing is removed from use.stable.mask he gets tricked a second time by suddenly a useflag popping up. (OK, this time, he *does* get informed and has a clean possibility to change, so this time his surprise is limited). > Which wouldn't happen if package.accept_keywords didn't implicitly > unmask flags. Exactly. This is why it becomes a dependency hell. But wouldn't removing this go against the purpose of use.stable.mask? > I don't get this. A masked flag is equivalent to a disabled flag. What > would cause the rebuild then? All python versions are use.force'd in this package. However, those which are use.stable.mask'ed are not use.force'd, because use.stable.mask overrides use.force (which makes sense). So if the use.stable.mask entry changes, the active USE-flags in the package change automatically, and the user cannot do anything against it (except modifying the profile).
