From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DEDF4138334 for ; Tue, 6 Aug 2019 16:28:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12750E0809; Tue, 6 Aug 2019 16:28:27 +0000 (UTC) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 99E38E070D for ; Tue, 6 Aug 2019 16:28:26 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id b13so41782107pfo.1 for ; Tue, 06 Aug 2019 09:28:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=HjkDgsujbSDc11loe4H7jYKi7d7UoqB2Ci6MmznQP+w=; b=B/Rn5X+hg5RsHeZeKRFCZK1kOl74ugCTUrTKqU7VqHmKkeVtT6ywrEeDpsrZR7mqru CejAmwQnIoRZqtB29JBs1MnZGcrkDtHM0UOTX0EtPNT3eF81jq8TNVLf7RkUyKhAR+NK G1NWccfcro9EdNTMHPtQ36wtq6NBfOuNRwTOTcEf/ZL2JZaXdC15IXD73SKCLbrw4Z0o wPczCY7kF0dmxI0ayYy7H5OjGaTzkWpDcpxzCmxO1vFJ7JL01EEUPBXTVpDNLmMeDiDa liyqxBd9DzpifYa0IJf8fZQYy8EPu0I2OkO8IpbVrtH0hDrIBFALwc3F1Un1DHNMPDTc UOPw== X-Gm-Message-State: APjAAAVYPS+DHFS435Xia25U/ignffIGNl9YrZ3rnsNpun5ny48cHSk+ lRADSEUi++57ksLW/yzbOO0nt9U/GbI8N+MBexibm990 X-Google-Smtp-Source: APXvYqwP+BesGHU/CnN/mZ5YxCMxwqGk4Yk275af/SqGibAhZxuUx71DXp/vlKprfUT5T7B9huwPqujRRtf9XMKC8pk= X-Received: by 2002:a63:3407:: with SMTP id b7mr3802503pga.143.1565108904663; Tue, 06 Aug 2019 09:28:24 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <11147c49836aa1983da6a4a546fdf116@dyndn.es> <2332946.CxK0Tlp8m7@localhost> <86327492-b40a-fa37-83b3-c58b571b9685@spamtrap.tnetconsulting.net> <1589750.hRPUKH7mkQ@localhost> <7264cb95-6c1f-560b-e04e-2b9303e1485e@spamtrap.tnetconsulting.net> In-Reply-To: From: Rich Freeman Date: Tue, 6 Aug 2019 12:28:13 -0400 Message-ID: Subject: Re: [gentoo-user] Re: USE flag 'split-usr' is now global To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4f6bef35-ef8d-4ac2-9b3d-e14dd377f198 X-Archives-Hash: 7fafa600d172bc7bea2c5d692d3e6863 On Tue, Aug 6, 2019 at 11:54 AM Canek Pel=C3=A1ez Vald=C3=A9s wrote: > > Arguing against this trivial (and IMHO, elegant) solution is tilting at w= indmills. Specially if it is for ideological reasons instead of technical o= nes. > ++ Some of the solutions I've seen tossed out in this thread are more complex than just building your own initramfs from scratch. An initramfs is just a userspace bootloader that runs on top of linux. Nobody has any problem with conventional bootloaders, and if you want to do anything with one of those you have to muck around in low-level C or assembly. There has been talk of gathering up all the stuff you need from /usr to bootstap everything, and then adding some scripting to mount everything. The proposals have been to shove all that in / somewhere (perhaps even in /bin or /sbin). If instead you just stick it all in a cpio archive you basically have an initramfs, and you don't need to have cruft all over your filesystem to do it. There are already configurable and modular solutions like dracut which do a really nice job of building one, and they make your bootstrapping process infinitely flexible. If you want root to be a zip file hosted on a webserver somewhere that isn't a problem. If you want root to be a rar file on a gpg-encrypted attachment to a message stored on some IMAP server, you could do that too. To make all that work you can just script it in bash using regular userspace tools like curl or fetchmail, without any need to go mucking around with lower-level code. Then once your root filesystem is mounted all that bootstrapping code just deletes itself and the system operates as if it was never there (strictly speaking this isn't required but this is usually how it is done). I doubt we'll see a /usr merge anytime soon, or any huge rush to break a separate /usr completely without an initramfs. However, there are already use cases known where a separate /usr can cause problems without either an initramfs or some kind of early-boot shell script (there have already been solutions tossed out for that which are much simpler than the ones in this thread). The biggest example I've heard is bluetooth keyboards - that was what made most of the zealots give up on supporting anything that could possibly be needed for bootstrapping being in /, as bluetooth has a bunch of deps and at that point you might as well shove gnome in /bin. So, for the forseeable future your system probably won't break if you are using a separate /usr, but if it does the policy has been established for a long time that nobody is obligated to fix it (nor are they prohibited from doing so). Really, though, you should take the time to appreciate an initramfs whether you decide to use one or not. They're a really elegant solution to the problem. Sometimes I think that half the objection is due to the fact that they use cpio which is a bit obscure - if they were tarballs people would be tearing them apart and playing with them more. --=20 Rich