Dnia 2013-11-13, o godz. 10:28:02 Martin Vaeth <va...@mathematik.uni-wuerzburg.de> napisał(a):
> 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. For example, consider
Python 3.3. In order to get proper testing of it on testing, we had to
enable support for it in packages. But when we introduced that support,
the package immediately gained a dep on python:3.3.
If the package was supposed to go stable, we would either have to
stabilize Python 3.3 (too early for that), wait for Python 3.3
(resulting in very long to infinite) or drop Python 3.3 support. There
were even cases when I had to revbump a package in order to keep
'limited' revision to stabilize and 'full' to keep testing.
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.
> 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:
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?
It's easy to use words like 'clear message' when you want to prove your
point. And I have no idea what you mean by 'something everybody should
be able to handle', unless you assume that the main purpose of a stable
system is to turn it into mixed-keyword system.
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.
> 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).
If you have a problem with USE flag being masked, you unmask the USE
flag. It is simple like this.
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.
If you unmask testing package just to get testing keywords, you quickly
lose the point of having stable keywords. Putting just the stable
versions is a pointless nightmare.
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.
> 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.
It's magic only because you did it wrong.
> 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).
Which wouldn't happen if package.accept_keywords didn't implicitly
unmask flags.
> 2. Just a few days ago dev-lang/python-exec:2 became stable
> on amd64, but dev-python/python-exec:2 is still ~amd64.
And this was a bug that would have been fixed if you cared reporting it
straight to us rather than kept is as an argument.
> 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.
I don't get this. A masked flag is equivalent to a disabled flag. What
would cause the rebuild then?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
