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 120841381F3 for ; Fri, 21 Dec 2012 08:11:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC53B21C0A6; Fri, 21 Dec 2012 08:11:21 +0000 (UTC) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) by pigeon.gentoo.org (Postfix) with ESMTP id BF29221C06F for ; Fri, 21 Dec 2012 08:10:46 +0000 (UTC) Received: from [212.54.42.137] (helo=smtp6.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tlxgs-0001fY-5K for gentoo-dev@lists.gentoo.org; Fri, 21 Dec 2012 09:10:46 +0100 Received: from 54698b76.cm-12-2c.dynamic.ziggo.nl ([84.105.139.118] helo=data.antarean.org) by smtp6.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1Tlxgq-0003F0-8Z for gentoo-dev@lists.gentoo.org; Fri, 21 Dec 2012 09:10:46 +0100 Received: from eve.localnet (eve.adm.antarean.org [10.55.16.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPS id E809D124C for ; Fri, 21 Dec 2012 09:10:38 +0100 (CET) From: "J. Roeleveld" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: eudev project announcement Date: Fri, 21 Dec 2012 09:10:22 +0100 Message-ID: <1410550.8z1d0Jc2Uc@eve> User-Agent: KMail/4.9.3 (Linux/3.3.8-gentoo; KDE/4.9.3; x86_64; ; ) In-Reply-To: <20121220093136.1dbd23f8@pomiocik.lan> References: <20121215203359.4552d807@pomiocik.lan> <71370075.XjM0oziCTt@eve> <20121220093136.1dbd23f8@pomiocik.lan> 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 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Ziggo-spambar: / X-Ziggo-spamscore: 0.4 X-Ziggo-spamreport: RDNS_DYNAMIC=0.363,T_RP_MATCHES_RCVD=-0.01 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 89018652-4e08-437f-8cf6-8505560d587d X-Archives-Hash: 507b19c4133fbd52e7ab431a9432746a On Thursday, December 20, 2012 09:31:36 AM Micha=C5=82 G=C3=B3rny wrote= : > On Thu, 20 Dec 2012 00:27:26 +0100 >=20 > "J. Roeleveld" wrote: > > On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote: > > > On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote: > > > > On Mon, December 17, 2012 22:31, Greg KH wrote: > > > > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:= > > > > >> Olav Vitters wrote: > > > > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote= : > > > > >> >> As I said in an earlier email, Lennart Poettering claims = that it > > > > >> >> does > > > > >> >> not work. We are discussing some of the things necessary = to make > > > > >> >> it > > > > >> > > > > > >> >work. > > > > >> > > > > > >> >Just to repeat: > > > > >> >In this thread it was claimed that a separate /usr is not > > > > >> >supported by > > > > >> >systemd/udev. > > > > >> > > > > > >> >A case which works with latest systemd on various distribut= ions. I > > > > >> >checked with upstream (not Lennart), and they confirmed it = works. > > > > >> >I > > > > >> >can > > > > >> >wait for Lennart to say the same, but really not needed. > > > > >> > > > > > >> >I assume this will again turn into a "but I meant something= else". > > > > >>=20 > > > > >> Olav. > > > > >>=20 > > > > >> Lennart has stated that he considers a seperate /usr without= init* > > > > >> broken. > > > > >=20 > > > > > Yes, as do I, and so do a lot of other developers. > > > >=20 > > > > It is only "broken", because upstream decided to move everythin= g into > > > > /usr > > > > that was previously in /. > > >=20 > > > No, not at all, please see the web page that describes, in detail= , the > > > problems that has been going on for quite some time now, with the= /usr > > > and / partitions and packages. > > >=20 > > > =09http://freedesktop.org/wiki/Software/systemd/separate-usr-is-b= roken > > >=20 > > > One good solution to this issue is to move everything into /usr, = and > > > that's something that has wonderful benifits in the long run, and= is > > > something that I expect all Linux distros to eventually implement= . > > > Those that don't, will suffer because of it. > > >=20 > > > Again, see the web page for why moving stuff into /usr is a good = idea > > > for the reasons behind this. > > >=20 > > > =09 http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > >=20 > > Example: /usr Network Share > > When /usr is on a network share, why not add a / on network as well= ? > > I have multiple systems and as they all have different uses, they a= ll have > > different software installed. > >=20 > > Example: Multiple Guest Operating Systems on the Same Host > > See answer to previous example. > >=20 > > How many environments actually currently exist where a shared /usr = is > > being > > used? >=20 > Are you aware that these environments are actually one of the most > important reasons for moving everything to /usr? I don't know what > hackery you're using to keep the systems in sync and working but it i= s > braindead enough. An init* needs to be kept in sync with the rest of the system as well. = As that=20 is a compressed filesystem, it takes a lot more effort to keep that in = sync in=20 comparison to a "normal" filesystem. I consider having to write scripts to unpack, modify and repack an init= * to be=20 more hackery then to keep a bootable root-filesystem working that can m= ount=20 all the filesystems needed for the whole environment. Anything needed to mount /usr, /var, /run (and any other part needed fo= r the=20 boot-process) should not be allowed to depend on anything in any of tho= se=20 directories prior to those being mountable. > The difference between keeping part of the system in rootfs > and initramfs is that you can discard initramfs after using it. It ca= n > be anything which is enough to get the /usr mounted and system > starting. Files on rootfs *have* to be in sync with those on /usr > or you're getting random failures. The same is true for an init*. If an update of part of the OS leads to subtle changes in the filesyste= m where=20 older versions can no longer properly access them, the init* is broken.= -- Joost