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

[Martin Vaeth]

Tom Wijsman <TomWij@g.o> wrote:
>> 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

We can make a vote, but I would be very surprised if there are
many stable users without any unstable package.

>> 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=3D"minimal" could be broken on a certain package because it removed a
> bit too much, thus it could be stabilized with USE=3D"-minimal" forced.

As I said, it is a technical means to solve a social issue:
Instead of communicating to the users that Gentoo does not consider
USE=minimal stable, one *forces* USE=-minimal behind their back, even
if they should have decided to select it explicitly.

> Sometimes problems can be resolved by better communication too; perhaps
> there are things we can inform the user about in pkg_postinst

This would be the reasonable case for the USE=minimal example
(maybe even already in pkg_setup). There are also other ways to
communicate this to the user; I_KNOW_WHAT_I_AM_DOING names etc.
is another one.

> improve Portage to let the user know of a particular forced USE flag.

If you just remove use.stable.mask, portage will tell exactly
this to the user: That some package needs to be unmasked for
a certain dependency to be satisfied.
Then it is up to the user to decide whether he wants unmasking
or setting the use-flag. Instead making the choice behind his
back (against the use-flag) is bad IMHO.

> That are indeed the two approaches, I don't see a problem with putting
> the version itself in accept_keywords or overriding the profile;

Putting a stable version into accept_keywords will (correctly) be
considered redundant by all tools which cleanup your accept_keyword:
It makes no sense, and using it only to work around the issues
which use.stable.mask introduced appears plainly false.

Overriding in the profile of e.g. use.stable.mask cannot be done
for a single package; you can only negate a whole entry. In fact,
if you want something here, you are more or less almost forced
to negate all entries of {package.,}use.stable.mask
This is why I ask whether the latter must be there in the first place.

In fact, checking what actually is there, you find:

1. Hundreds of packages with abi_x86_32
2. python_{single,}targets_*
3. 5-10 packages with USE-flags like "unstable" or "clang" for which
   it should be clear for any stable user that he does not want to
   activate it without knowing what he is doing resp. caring about
   the dependencies.
4. Nothing else.

So practically only stuff which already caused grief plus very few
normal stuff which better should be communicated if it is not
obvious anyway.

>> The really bad thing is that this is happening by magic
>> "behind the user's back"
>
> System upgrades have to be done carefully; so, the user skipping it is
> something we cannot account for

So just to get it right:
There was something introduced to avoid communication which does
something behind the user's back which in many cases can be just
the opposite that the user wanted. You expect the user to check
the output carefully so that he can recognize that somebody is
trying to trick him, and if he analyzes the profiles he can
eventually find out what it is.
Do you really consider this better than reporting to the user
that some testing package is pulled in by a USE-flag he had set?
(Which would be the effect without use.stable.mask)

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

Any mask is displayed the same. But this is not the point:
stable.mask was introduced to avoid communication with the user
by trying to guess what he means (in contrast to: doing what he
writes in the config-files).
Now you expect him to read carefully output and even improve
output only that he can decide whether portage's guesses are
right or whether he has to work against his profile.

Such tools which try to be more clever than the user always
cause trouble. Please recall this mechanism which was used
previously to "guess" useflags based on installed packages
(I even forgot the name, since this was fortunately removed).
This is nothing compared to the magic which stable.mask forces,
since the latter cannot simply be overrided by configuring
package.use appropriately.

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

This discussion does not belong here; I decided for ABI_X86="32"
and expect portage to respect this decision and not disabling
it randomly for some packages just because I did not mark a
stable package testing.

Yes, I understand the mechanism and how to override it, but this
is all tricky and cumbersome: Essentially, you have to spend a
lot of time just to work against the stable.mask mechanism.
The intention was probably that this mechanism should be
helpful and simplify things, but it turns out that it does
just the opposite. So one should think it over and remove it
(or replace it by something better if one finds something).

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

Again, one might do a vote, but I would be surprised if not
80-90% of the stable users also have unstable packages.

> but note that this package had an accident, see the related
> news item for details.

This is why it took me so long to find out; of course, I thought
that the problem is related with the news while it was actually
related with use.stable.mask

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

Please read, what I had written: I have explained why this happened.
It is because use.stable.mask horribly interacts with the dependency
chain: Use flags change out of nothing if you are forced to add an
unstable keyword somewhere.

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

This is the point: You have an actual "useless" package which
due to use.stable.mask hinder dependencies from being corrrectly
resolved. And which even forces other packages to be rebuilt,
also because of changes only in use.stable.mask.

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

Exactly, but this is the only solution which portage can
find; again, because use.stable.mask implicitly changes the
dependency chain.

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

They provide exactly the same USE-flags, and whenever they
occur in profiles or dependencies they occur both or none.
So one has a hard time to guess why the git version satisfies
a dependency which is not satisfied by the stable version.
Of course, if one knows the answer (use.stable.mask), it is clear.
Instead of making things simpler for the user, use.stable.mask
causes problems to the user.
It causes much more problems than it solves: Actually the only
problem which it solves (or better: tries to solve) is a
communication problem...

> If it is due to the hell above, we warn users up front for that.

Most users mixing stable and unstable have valid reasons
for each case. Telling "we have told you not to do that"
only to keep a smart-ass mechanism which produces more
problems than it solves is a bad idea.

>> 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, [...]
>
> That is to be expected on such stabilizations, I doubt they are
> unnecessary

Only because some package which I have not even installed changed
its stability, it should be necessary that I reemerge everything?
And even *if* I should have installed it, the change of its
stability would make it necessary to reemerge my world?
Things appear very strange in Gentoo land meanwhile...