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 <gentoo-dev+bounces-51398-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; Fri, 4 May 2012 16:31:59 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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 <slong@rathaus.eclipse.co.uk>
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: <jo109a$4oq$1@dough.gmane.org>
References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120411051836.GA11133@linux1> <jm4a6h$6p3$1@dough.gmane.org> <201204281709.36713.vapier@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 ;-)