Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
Date: Fri, 04 May 2012 16:33:22
Message-Id: jo109a$4oq$1@dough.gmane.org
In Reply to: Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 by Mike Frysinger
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 ;-)

Replies