From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SQLRZ-00064G-VE for garchives@archives.gentoo.org; Fri, 04 May 2012 16:33:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7E367E06E8; Fri, 4 May 2012 16:33:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E6096E06BF for ; Fri, 4 May 2012 16:32:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 671831B4011 for ; Fri, 4 May 2012 16:32:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5.5 tests=[AWL=-0.371, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL79kVYraA_J for ; Fri, 4 May 2012 16:32:01 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 17FFA1B4026 for ; Fri, 4 May 2012 16:31:59 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQLQ8-0001yG-Q9 for gentoo-dev@gentoo.org; Fri, 04 May 2012 18:31:52 +0200 Received: from 91.85.61.115 ([91.85.61.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 18:31:52 +0200 Received: from slong by 91.85.61.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 18:31:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Fri, 04 May 2012 17:36:20 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120411051836.GA11133@linux1> <201204281709.36713.vapier@gentoo.org> 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-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.61.115 X-Archives-Salt: f304c109-f38c-460e-abf8-536b1f282875 X-Archives-Hash: c15407f49a896670480c090ee6622b75 Mike Frysinger wrote: > On Wednesday 11 April 2012 12:10:05 Steven J Long wrote: >> William Hubbs wrote: >> > Another issue to consider is binaries that want to access things in >> > /usr/share/*. >> >> I'm ignorant of which binaries do that? > > off the top of my head: Ah thanks, this is what I was after: interested in which ones make use of a rescue-shell or initramfs more difficult. > - this is why /etc/localtime is no longer a symlink to > /usr/share/zoneinfo/ - don't think that makes any difference to rescue situation. > - this is why we have copies for a few terminals in /etc/terminfo from > /usr/share/terminfo/ ... hopefully the one you're using is listed there - while unfortunate, I'd say ditto since user can always copy any required file themselves for their particular setup. > - this is why we have to delay running keymap and consolefont init.d > scripts until after /usr has been mounted (/usr/share/keymaps > /usr/share/consolefont /usr/share/consoletrans) - this is one that really is annoying; having your keyboard switched to US layout. It's not totally insurmountable from a UK keyboard, but I'd imagine eg a Dvorak user would have trouble. du -hs here, shows: 1.1M /usr/share/keymaps 1000K /usr/share/consolefonts 504K /usr/share/consoletrans ..which is nothing I personally would mind on rootfs, if it meant my rescue- shell used my keyboard layout. > - anything locale related doesn't work until /usr is mounted > (/usr/lib/locale /usr/share/locale) This doesn't affect me as I'm fine with en_US vs en_GB. 1.7M /usr/lib/locale 53M /usr/share/locale ..is a lot heavier, though. (Sorry, I'm not stating that anyone is going to want to maintain this, I'm just scoping out how much data we're talking about, and how it important it is. While latter might change according to user as here, it would be cool if it were nothing more than setting up a few symlinks during install.) > - passwd changing relying on cracklib dicts won't work > (/usr/lib/cracklib_dict* /usr/share/misc/) > I can see you might want the option after an attack on a host. NFC how viable moving and linking is (not sure what it uses in /usr/share/misc but I for one would love the pci and usb stuff [just over 1M] in rootfs. kk I know it's not going to happen officially ;) but libs are less than 300k here. >> (It's understood that you might not >> have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but >> on my system at least it only links to /lib64. > > /usr/bin/nano is a symlink ah d'oh, ta; i see it was switched back in 2004. >> > If a binary in /{bin,sbin} needs to access something in >> > /usr/share/*, you have two choices. move the binary to /usr or move the >> > thing it wants to access to / somewhere which would involve creating >> > /share. Actually there is another choice, but I don't want to go there. >> > That would be writing patches. Yeah, based on above, I'd feel okay about /lib/share/foo personally, linked to from /usr/share/foo on both bare rootfs with no mounts, and standard /usr. (Similar for /usr/lib/foo to /lib/foo.) If it's in /usr/{share,lib}/dir/* then the possibility at least of moving it fairly simply, exists. Otherwise you're into dealing with a build-system of one sort or another. Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)