Dnia 2013-11-13, o godz. 15:23:44 Martin Vaeth <va...@mathematik.uni-wuerzburg.de> napisał(a):
> 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. Did you ever do any serious package work, or are just discussing theory? Repoman is not a social tool. It's a technical dep checker, and if you start allowing exceptions to the rules, its output will *soon* become useless since you would have to filter out all the allowed exceptions and hope they didn't hide a valid issue. > > 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. 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? But it will be just a suggestion, you need to manually choose the older version if you want to follow it... Do you see now what you are proposing? > > 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). If it can easily be improved, then why didn't *you* improve it yet? Go for it, then tell us how easy it was. Then we can consider what to do next. > > 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. We must be having different users. Because as far as I know, we have users throwing quite-a-long emerge outputs from time to time. Of course, there are ricers too. The people who are going to mess up their systems and suggest others to do the same, just to prove they solve any problem in the worst way possible. > > 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? Are stable keywords a good idea if the user essentially only overrides them with package.accept_keywords? 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. > > 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? And by using 'package.use' you 'undo' USE defaults in packages and global flag defaults, and... why do we have USE flags at all? We're just all undoing stuff anyway. > Moreover, for use.stable.mask this cannot happen on a per-package basis. It's called package.use.stable.mask. > Perhaps one can introduce a better way to unmask use.stable.mask? Like what? > > 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? I mean stable-masked flags. So you get 2-in-1 with no clear indication that you got an extra unmask. > > 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). Then the user gets to rebuild python-exec which is a tiny C executable. Reverse dependencies are not rebuilt. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
