On Wed, 13 Nov 2013 14:25:11 +0100 Thomas Kahle <to...@gentoo.org> wrote:
> Hi, > > On 11/13/2013 12:39 PM, Tom Wijsman wrote: > > On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) > > Martin Vaeth <va...@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. > > This argument has come up several times, but is it valid? For more insight see http://comments.gmane.org/gmane.linux.gentoo.devel/87839 and I quote "quite a few bugs are closed as invalid when a mixed system is detected" as well as "mixing stable and testing is (likely) invalid when unmasking one package in the unstable branch causes (reverse) dependency resolution issues with another package in the stable branch". Not to forget that we often test with everything stable or with everything on testing; so, if you mix packages from both you end up in untested situations where dependencies do not match what we intend. Some of us fix them, but not everyone might; others might even just end up setting a dependency range because of the stable / unstable mix. Besides it being unsupported by some (I'll drop the "many" sound to it) there are also just users in general that suggest others to avoid it; simply because of the blockers and conflicts it brings along, it's something that works out well for users that deeply understand what is going on but for new users it is just a recipe for disaster. Regardless of that, in my opinion, we should avoid encouraging situations that result in having to deal with more unnecessary blockers and conflicts; but that doesn't mean we don't want to see it. The same link above highlights how it can help rather than obstruct Gentoo too. > For me > and other people I know, the main reason to use Gentoo is the > rolling release model and this implies that you can mix package > versions as long as version dependencies are satisfied. When the > dependency is "cat/package" then this should mean that it works > with every version. If it does not, then the ebuild's > dependencies should be updated. 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 except for some people that mix and come across it; so, effectively the version dependencies do not always match reality and therefore cannot imply that you can mix it. It's also very unrealistic to check every package for every bump; at least not with the amount of work compared to the amount of manpower we have, it does happen a lot and we are required to do so to some extent. But you will note that this ends up in situations where the new version just ends up being in package.mask for a long while, for example ffmpeg. Others are either new and forgot or might show a lack of care; which results in it being properly tested for non-mixed systems, but not properly tested for mixed systems. Enumerating all dependency versions is a quite busy job; we often rely on the restrictions listed in ./configure.{in,ac} but those are not always correct either, sometimes they are even just absent. > The handbook says nothing about "unsupported": > > http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=3 > > If "many" choose to change this policy, there is no reason > anymore for me to use Gentoo. 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... Note that it is merely unsupported by some developers, there are definitely other developers that support it; and this does not imply anything at all about our support venues. > >> 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? > > 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? > >> 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. > > Do you mean stable and unstable in this case, or in general? > > [...] General; but well, depends on how you mix things. A few packages won't hurt, any larger than that and blockers and conflicts are all around your ears... > In general I share the sentiment. The complexity of using > portage has increased a lot lately. Not only does it take long > to find out why things suddenly go wrong after tree sync, also > just the time until 'emerge -avUDN world' comes back with a > proposal has grown to several minutes where it was few seconds > when I started with Gentoo. Yes, while I'm not completely sure as it gradually changed; I have the feeling it was much shorter back in the days. Though it could be a bit of a bias because the amount of packages I use has grown since as well. > There has been a lot of effort to make revdep-rebuild unessecary, > but now that it is mostly implemented, I don't know if it was > worth the price. emerge-time_current = emerge-time_previous + revdep-rebuild-time is how it feels like for me; just a move of time, but I feel like it's not the right one. Anyhow, there are parameters to disable the subslots; just as well you can disable preserved-rebuild. Maybe it does make more sense to run a longer process once after all emerges, than opposed to have it run again on every single emerge. > I spend more time now just reconfiguring > keywords to update the system than I spent back in the old days > where revdep would just fix things. Not sure what the relation between keywords and revdep-rebuild is. > If the answer is, that I > should not mix arch and ~arch, then I'll not use Gentoo anymore. We suggest you not to; there are enough people around to give support for it regardless, I'm yet to come across a problem that can't be fixed. Please don't take my words for final and consider other people's opinion on this thread as well; I don't know the numbers, so it is hard to tell what the general opinion on this is. Parts of this post are therefore personal opinion or a personal view not necessarily matching by opinion, other parts are quoted and/or might match the truth. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
