[gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

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 ;-)