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 E99BE59CAF for ; Sat, 9 Apr 2016 10:56:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3310221C07E; Sat, 9 Apr 2016 10:56:50 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4500921C002 for ; Sat, 9 Apr 2016 10:56:49 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id f1so30154095igr.1 for ; Sat, 09 Apr 2016 03:56:49 -0700 (PDT) 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; bh=D2gGZFC/sNH5AUVNN0LrlQFKvGD9oPrkOGkRgoG81UA=; b=Z0N2jfLQOGOvSjymPOjxNuw1idNAKZpmBr/1dQI6oBKPlUiBcdIX4+ExOmK7T+kGUh lxetijwnc8XJ74f5sKFh+EYobrEGjMvWMws0A++PBnzry9/FdCnxsSXJ9B197Xi0CqS7 x9IVh+InKNgp+is/hMQ4To5HhDn3Ufapfy0UiYAUWFcHuwtiJk22fkt/f10TeKZwBGaq cmFOCGvOERnh+zwddwncUGamOA7ug4FJ9y8i1V65uh1AP2tXfsATg9KRmuhQq2z29ZMa 88K170Lwt+Ni8VCmuflJHdTdnoG9nUx3wwMODs5bL7r14bLhL5zI2Zp1/50gU4DO8AZw yo+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=D2gGZFC/sNH5AUVNN0LrlQFKvGD9oPrkOGkRgoG81UA=; b=gP/d66COTx2jD0b553PiVrwRVLyAL+szKtxohN92msFw1+BgZFEuNh9jV2oGKH9AoE 3ZJqy8gcq6Njd9L6RFti0b36MzrXvCPes2rzPnoV5dIdteL3PXeGP32Xgg6jgzselz/9 2MTMAwBLLBAVuDAUxHdvz5QGn6yFFeOI/AVJTWNdRXOZQAuSeWyt8huh8Q7wUf3nhmac /T9whzKIfz67+MxkkYY2kTtZ4Hq3pNjVqkpIVpOKK6J4lZqoRgERz6WkdP9WVsX17pvv VUjkSKUafM/IdPVtKJNzZSDdMrKZMxf7mms0uEH7Q1UP0CXA7r6+RVEhwAO0NzGkED2p uygQ== X-Gm-Message-State: AD7BkJIbE4/FESYL1ego7K+RGGAqgr+1nu3sk4fG+8BjEXdB8ZViBna4eTJHBsV/sSL663LzLg54klXcxB74vw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.132.102 with SMTP id ot6mr7772218igb.97.1460199408331; Sat, 09 Apr 2016 03:56:48 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.64.52.72 with HTTP; Sat, 9 Apr 2016 03:56:48 -0700 (PDT) In-Reply-To: <57087FD7.5030900@gentoo.org> References: <5706A7A6.3080402@iee.org> <57070bbd.9a48620a.a07cf.3177@mx.google.com> <57070c95.0714320a.ed102.1995@mx.google.com> <57079677.9010900@gentoo.org> <57082EA8.6060505@gentoo.org> <57085007.87059d0a.c79c1.24f6@mx.google.com> <570856D4.8080900@gentoo.org> <57085cb7.d3adca0a.1a02a.2879@mx.google.com> <57086017.6060501@gentoo.org> <57087FD7.5030900@gentoo.org> Date: Sat, 9 Apr 2016 06:56:48 -0400 X-Google-Sender-Auth: aRBeKn_3Puz6mvzY3q04cjsLYV8 Message-ID: Subject: Re: [gentoo-dev] usr merge From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: fefb25d2-b712-494a-a79f-d5b7fe15d0eb X-Archives-Hash: 298a563da4d6308087da4da4391f9327 On Sat, Apr 9, 2016 at 12:06 AM, Anthony G. Basile wrote: > On 4/8/16 11:03 PM, Rich Freeman wrote: >> >> What problems are you anticipating, especially in light of the fact >> that many distros actually do it this way already? > > RBAC policy files for one. You'll probably break every single hardened > gentoo server out there. I wasn't suggesting that some adjustments to packages wouldn't be needed to accommodate the change. I was talking about the long-term, after any necessary changes are made? > > scripts and programs that assume different executables with the same > name at different points along the path, eg I know a company where > they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh. I get your point, but the actual case you cited wouldn't be affected by a /usr merge. I appreciate that there are cases where something might be affected (though users shouldn't be sticking wrappers in /usr/bin anyway without packaging them). >> >> I don't really have a problem with making it optional or the default. > > if we don't make it optional we're going to cause some serious headaches > for people who are invested in the current status quo. If you want to use a distro where you can heavily invest in the status quo and not expect it to change I think you'd be better off with a distro like RHEL, which targets this niche almost explicitly. But, as I've said, I see no reason not to make it optional. A big part of why we CAN get stuff like this done is that we let people migrate themselves at their own pace. >> >> It can also be left up to the maintainers, and of course somebody >> could even fork baselayout/etc if they wish and virtualize it in >> @system. Most things in Gentoo don't actually require a consensus to >> move forward, especially if they aren't defaults. > > if we deprecate the linker scripts in /usr/lib by stubbing out > gen_usr_ldscript, then its not as simple as "maintainer's choice". Well, I don't hear toolchain asking to retire that function. If it is their desire to stop maintaining it, then somebody else could of course take over for them and preserve a choice. > >> >> In any case, what is the point of this thread? If somebody wants to >> implement a merged /usr what exactly is stopping them from doing so? > > i'm against something that doesn't maintain backwards compat. > Well, we all have the freedom to fork baselayout if it isn't maintained the way we want it to be. Currently, no policy exists that says the baselayout maintainers can't just maintain the package however they want to (other than the general QA practice of announcing/coordinating changes in advance with trackers/etc). I suppose if somebody wants to propose a policy that says otherwise it is their freedom to do so. Personally, I think our users would be better-served by making it a choice. That might be a choice that comes with some pros/cons, just like the choice to use an initramfs, or the choice to run systemd, or any other choice that we trust our users to make. -- Rich