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

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7518 bytes --]

On Wed, 13 Nov 2013 10:28:02 +0000 (UTC)
Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]