[gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Martin Vaeth]

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:

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).
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).

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. 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.

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).

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:
Portaqe wanted me to emerge the git version of
dev-lang/python-exec:0 and reemerge dozens of packages.
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, 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.

This is completely confusing since nowhere the git-version
is marked differently than the non-git version.

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.

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.

Best Regards
Martin