From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BCBDD138A1A for ; Wed, 21 Jan 2015 16:56:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9D76E092E; Wed, 21 Jan 2015 16:56:14 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 52ED5E092A for ; Wed, 21 Jan 2015 16:56:14 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id ft15so21607174pdb.5 for ; Wed, 21 Jan 2015 08:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=nWQsTa/7q+6B3C6gc9n31cP9oK+vgUhCcNsU3EU5FBo=; b=wArbQO/eD/0gyRE2CS+UDAAnJAvwPbc/GS4oXZ5VGQJikjBce7THszcnMAr5jRFPlP PbvkhPB3vbSsYC5tVj0ZkKNkx7GH70YVk/YndCZoritbwngl89j+pt8I6UMayCZuoGbb +atThEBdvmtwnvdPaN5AuS/B53FSThEEijbgd87PTUxb7xLBeVhNiP793jxPsY40WeXK UC1l41TsadcbnYtk1S2e1wG4ZQOs7RywqHniFzLmGgvFt5er9xiwQt/yuVYDx3FGQHXo WWCS2BDoRsvNkC+R74m/SOyWE0mHMr6LxAQxchXMEmxhVQOOKMhfYuTNeVzS1D7plXjm vCpA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.67.5.42 with SMTP id cj10mr63937225pad.65.1421859373323; Wed, 21 Jan 2015 08:56:13 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.70.1.103 with HTTP; Wed, 21 Jan 2015 08:56:13 -0800 (PST) In-Reply-To: <54BFD57E.3020704@hasufell.de> References: <20150114034323.GA22358@comet.hsd1.mn.comcast.net> <54B7D189.1000108@gentoo.org> <20150115191001.GD22358@comet.hsd1.mn.comcast.net> <54BF2444.20106@gentoo.org> <54BFD57E.3020704@hasufell.de> Date: Wed, 21 Jan 2015 11:56:13 -0500 X-Google-Sender-Auth: RumP9wEx4DhVaUiO-KrivEwvcsg Message-ID: Subject: Re: [gentoo-project] Some focus for Gentoo From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 6457714f-b446-405d-b5ab-d1f639139a16 X-Archives-Hash: f5979a8003c658b01d7c44357204aeac On Wed, Jan 21, 2015 at 11:36 AM, Julian wrote: > > We would need much better tools and PM support for overlays. I've talked > about this too and there are examples of at least two distros that are > running a more decentralized model: > 1. NixOS, also see my thread on nix-dev about how they want to ensure > focus [0] I still don't get how NixOS avoids some fundamental issues. As I understand it they assign a unique ID to every build of everything, and the dependencies are expressed in the same way. So, my build 123 of appfoo v1.1 depends on build 456 of libz v2. Your package might depend on build 457 of libz v2, and that is fine since both versions will be installed side-by-side. Then we get to have two copies of libz in RAM and maybe build 456 has a security vulnerability. It is better than static linking, but not by far. Sure, we could do that with Gentoo, but I'm not sure this really addresses the concerns you brought up, like... >> How >> can we have both games.eclass and no games.eclass but due to a >> technical/methodology change there are now less problems? Ditto for >> the two multilib implementations? >> > > Well, for once: forking an overlay is easier than forking the whole > gentoo tree. > But that's not necessarily the main point. Ideas would not be decided by > "who does something first in the tree", but by more dynamic processes > about approval in the community. Someone starts a repo and does stuff. > If people like it, they are going to use it and focus their contribution > there. So, which is it? You point out that we have inconsistencies in our tree because we have games.eclass but we don't force everybody to use it. How is it better if the games are scattered across 47 overlays instead, and some of them use games.eclass, others use something else that sticks games in an entirely different group/path/whatever, others follow upstream, and maybe half the overlays do security updates and the other half don't? Maybe half of them use the multilib eclass and half use portage-multilib. So, are we OK with inconsistencies or not? If we are OK with them, then why complain about it? > >> I think that a major shakeup only makes sense if we can actually >> demonstrate a new model in operation, and it actually solves our >> problems. >> > > I've already given two examples of a new model in operation. Also, I > haven't said "let's do this tomorrow". IMO it will never happen anyway. > I am convinced that gentoo will rather die slowly, because people are > afraid to change the course which leads us to a nice thick wall, because > we might derail. > I'm still not sure if it will die because of "lack of manpower" or > because our technology is so messed up that it becomes unusable. So, I'm not convinced that we won't find our way, but if Gentoo stops existing because we've all found a better way and moved on to it, then really there is no loss unless you're really attached to the name, "Gentoo." None of us own stock in the Gentoo Foundation. If something new already exists and is doing it better, and we all just decide to switch, then we all reap the benefits. However, it seems likely to me that if there were an overwhelming sense that a new model would really work for most of us, we'd change. The problem is that not everybody is here for the same reason, and we're best off trying to tap into that rather than fighting it. -- Rich