[lsb-discuss] Call for Topics - 2012-02-15 conference call

[Robert Schweikert]

On 02/14/2012 03:36 PM, Bruce Dubbs wrote:
> Robert Schweikert wrote:
>> On 02/14/2012 02:45 PM, Bruce Dubbs wrote:
>>> Robert Schweikert wrote:
>
>>> Not everybody wants to use an initrd. Are you suggesting is should be
>>> mandatory?
>>
>> Nope. However, all distributions use and initrd and those admins that
>> do not use the distribution provided boot mechanism are sophisticated
>> enough such that they can handle the migrated binaries or they can
>> break the link between /bin and /usr/bin and add what they need to /bin.
>
> It depends on what you define as a distribution. All is a pretty
> encompassing word.

openSUSE, Gentoo, Fedora, Debian, Ubuntu, Mint,......

I do not consider "roll you own" a distribution. The last time I checked 
LFS (Linux from scratch) it also provided instructions to use an initrd.

>
>> Not using an initrd as provided by the distributions requires
>> additional custom work by the sysadmin in the current setup and this
>> work increases only slightly if binaries are migrated to /usr.
>>
>> IMHO having the opportunity of a truly shared ro /usr outweigh the
>> extra work people not using an initrd will have to do.
>
> It would appear to me that the reason /usr is required is that
> developers do not pay attention to the customary protocols.

Or you could argue that the customary tools just happen to place things 
in /usr by default and that the GNU toolchain should be changed. But 
again, I do not want to debate the merits of the merge or developer habits.

> Is it really
> that important, for instance, that usb.ids and pci.ids be places in
> /usr/share instead of, say, /lib/device-data.

You can argue that point with the upstream developers. Quiet frankly I 
do not care where all this stuff lives. I would just like to see some 
unification and consistency among Linux distributions. With the /usr 
merge there appears to be a chance to reach this goal.

>
> Having a shared ro /usr is not that hard if the right programs are
> available in /bin and friends.
>
>>> Originally, the purpose of /bin, /sbin, and /lib was to be able to mount
>>> other directories at boot time.
>>
>> Well, according to this little historical recap
>> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>> /usr directories were created because of overflow and at the time
>> physical limitations.
>
> Isn't that essentially what I said?
>
>> However, a "modern" Linux system does not boot properly already if
>> /usr is not either on the same file system as / or not mounted first
>> thing, i.e. in the initrd.
>
> And why is that? Developers don't follow the standard, so we must change
> the standard.

No, that is exactly the point. I claim this merge can be accomplished 
without changing the standard. But then again, I might not be correct, 
and  that is exactly what I am trying to figure out. So far no one has 
made a convincing argument that says, merging things into /usr violates 
FHS, because FHS states.....

As I pointed out in the original message the way the FHS is written at 
the moment, and the way I (and some others) interpret the FHS, the move 
falls within the confines of the FHS.

I am at this point not proposing to change the FHS or make any 
modifications to the draft for 3.0.

>
>>> This now seems to be migrating to initrd
>>> with an associated decrease in the visibility of what is happening. In
>>> some cases, the initrd is needed, but in most cases, it isn't.
>>
>> I didn't want to debate the pros and cons of the move on this list,
>> there have been plenty of debates about this already, and they are
>> still ongoing. What I am after is a discussion on tomorrows call and a
>> clarification of whether or not the move of binaries from / to /usr
>> does or does not violate the current released FHS and LSB.
>
> Since the FHS is being updated, I'd think this discussion is appropriate
> here.

Well, the proposed FHS 3.0 does not change section 2.3, if I recall 
correctly. Section 2.3, I think is at the heart of the matter.

Robert


-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei at suse.com
rschweik at ca.ibm.com
781-464-8147