Tom Wijsman <tom...@gentoo.org> wrote: > > and I quote "quite a few bugs are closed as invalid when a mixed system > is detected"
I think nobody is speaking against this possibility: If it causes too much grief to the maintainer to list all blockers explicitly, I think everybody can agree if he says that if it breaks you keep the pieces. However, it is a different thing to treat mixing generally like ricing and to introduce mechanisms which - as my example hopefully show - can be *expected* to break usability of a mixed systems: There are valid reasons to not have a testing system (besides the obvious desire for stability another one is too frequent updates), but there are also many valid reasons why you need some package(s) which pull in a lot of unstable dependencies. I think the "typical" use case even is a mixed system, since most systems will require some special applications (related to the main task this system is supposed to do; perhaps development of something which needs a lot of unstable packages) while on the other hand this does not mean that *everything* in the system should be testing and frequently updated. BTW, another reason for mixing which was not mentioned yet is users of multiple architectures (e.g. amd64 and x86) wanting to have the same versions installed (e.g. to use the same tarballs); although, as a rule, amd64 and x86 do not differ *much*, they usually always differ in a few packages since some team always stabilizes first. > Given that maintainers often test against test versions and that arch > teams often test against stable versions, nobody really tests the rests > of the situations [...] > > It's also very unrealistic to check every package for every bump Again, I think nobody expects that there never will be any trouble on a mixing system. But it is one thing whether this trouble occurs from time to time - when things are running badly - or whether the package manager uses a mechanism which can be expected to break on mixing system. > Which policy? It does not say anything about "supported" either. I > believe that its intention has always been to change it for some > packages, not for wide sets of them; the former doesn't cause much > problems, the latter is a recipe for disaster... With use.stable.mask you get problems even with one unstable package unless you verify manually that no useflag related to this package is in use.stable.mask And if it is, you are lost in the sense that you have to eliminate the provided use.stable.mask. So what has use.stable.mask achieved? It has forced to you to eliminate the mechanism and nothing else. >> We could consider reducing the feature set of portage and live >> with the "problems" that arise. When I started using Gentoo a >> package could simply not go stable until all dependencies for all >> USE flags were also stable. Masking USE flags was reserved to a >> short list of very special architecture depend special cases. >> >> [...] > > Doesn't that block stabilization too aggressively? Maybe, maybe not. It is exactly this social/political question which is attempted to be solved by technical means with use.stable.mask. This is what does not work: You cannot solve this question (whether to relax this policy; are there any exceptions valid and if yes which one) by a technical tool which forces a certain other decision onto the user. It is just shifting the problem and causes additional headache.
