On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) Martin Vaeth wrote: > Hello. > > The new "features" use.stable.mask and package.use.stable.mask > have turned maintaining systems with mixed ARCH and ~ARCH keywords > into a nightmare: They are considered unsupported by many; so, going down that path you need to be acquainted with Portage enough to keep a consistent system. > Similarly to the (fortunately dropped) concept of forcing > useflags if certain packages are installed this forces a > magic on the user which can hardly be managed since it is > not clearly presented to the user but hidden in some profiles. > > 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). That's one approach, it might also be used when a package can be stabilized but a certain of feature of the package cannot; eg. USE="minimal" could be broken on a certain package because it removed a bit too much, thus it could be stabilized with USE="-minimal" forced. Anyhow, I think we should make sure to weight "why we need to have it" against "how it bothers which users"; and not just focus on users alone. And other than that, are there alternatives? Something we can do better? Sometimes problems can be resolved by better communication too; perhaps there are things we can inform the user about in pkg_postinst, or improve Portage to let the user know of a particular forced USE flag. > Solving social problems by technical means is never a good > idea: > > While the former gives the stable user a clear message > what is going wrong (after all, many stable users want > some package which has not a stable version yet, so this > should be something everybody should be able to handle), > the latter hides causes and makes things almost unpredictable: > > Even if the user has put the dependency into > package.accept_keywords, he will not be able to use the > USE-flag on his packages unless > *he puts stable versions into package.accept_keywords* > (or - simlarly worse - overrides the profile). That are indeed the two approaches, I don't see a problem with putting the version itself in accept_keywords or overriding the profile; furthermore, overriding forced and/or masked USE flag is the exception, it doesn't happen so frequently so I doubt this is a huge problem. > The really bad thing is that this is happening by magic > "behind the user's back", i.e. contradicting the user's setting > of USE-flag and package.use: If the user does not carefully > read emerge's -v output, he even does not get informed that > the support for his unstable package is dropped from the > stable package, despite he might have specified the corresponding > USE-flag globally. System upgrades have to be done carefully; so, the user skipping it is something we cannot account for except perhaps providing support for the user receiving some kind of verbose summary of such forces / masks being present at the end of the emerge output. But you'll have to contact the Portage developers to achieve such improvements. > Even worse, even when reading the output > carefully, the user cannot understand the reason: > Since there are many reasons why use-flags can appear in () > he will probably not even conjecture that actually something > will not be working as he expected. Most of these reasons can be uniquely determined from the output; but indeed, some might yield the same output, but this is again something that the Portage developers can improve and not a reason for removal. > Here are some other examples of negative effects happening > just recently to me, ordered from not so severe to very bad: > > 1. For several reasons I always want the most current > emul-linux-x86* libraries, so they are in package.accept_keywords. > Due to global ABI_X86=32 (which I also want), this forced me > of course to put several libraries to ~amd64 since only > new version support this. Some of the libraries are actually > stable, so I have removed them from package.accept_keywords. > So far, so good. > But suddenly portage spitted unexplainable dependency errors, > and I only expert users manually reading the profiles can > understand that the reason is that use.stable.mask requires > that stable versions need to be keyworded ~amd64 > (or use.stable.mask has to be overridden in my profile). This confuses me; isn't the goal to have one multilib apprach or the other? Especially due to the blockers between them. I agree Portage output can be better, I'm not sure if use.stable.mask is really the problem here though; but rather the nature of mixing them. > 2. Just a few days ago dev-lang/python-exec:2 became stable > on amd64, but dev-python/python-exec:2 is still ~amd64. > Just to be sure to not miss anything, I have put the latter > into package.accept_keywords, and hell break loose: Hell indeed breaks loose if you mix stable and unstable; but note that this package had an accident, see the related news item for details. > Portaqe wanted me to emerge the git version of > dev-lang/python-exec:0 and reemerge dozens of packages. This is a consequence of that hell; if you don't agree and this is due to the Portage tree, please show the dependency chain that causes this. > I needed hours to find out what is the actual cause: > The package.accept_keywords caused the use.stable.mask of > python_targets_pypy2_0 und python_targets_python3_3 to become > ineffective for dev-python/python-exec, It doesn't matter, dev-python/python-exec installs no contents. > but of course it is still > effective for dev-lang/python-exec which is not be the case > if I unmask the git version of dev-lang/python-exec. Which one is not meant to do anyway; and from what you wrote, I don't think you intent to either. > This is completely confusing since nowhere the git-version > is marked differently than the non-git version. Marked in which way? One is stable, the other unkeyworded. > So, yes, portage's behaviour can be explained, but, no, > it is not understandable by a user who wants portage > to report what is really wrong and who does not want > to check manually by reading all profiles and hunt down > for reasons why certain flags are magically forced/disabled. Which output are we discussing here? If it is due to the hell above, we warn users up front for that. > 3. As a side effect of 2., I realized that libreoffice and a dozen > further packages get forced a rebuild. So, if eventually > python-3.3 becomes stable and is removed from use.stable.mask, > all stable users will have to rebuild almost their whole world, > because python-exec then has one more "dummy" USE-flag. The same > will happen again if pypy-2.0 becomes stable. > So a lot of unnecessary rebuilds happen to stable users because > of {package.,}use.stable.mask which most of the developers > (who are often ~amd64 users) do not realize. That is to be expected on such stabilizations, I doubt they are unnecessary; if I misunderstood, feel free to give an example. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D