[OE-core] [PATCH 2/2] tzdata: install /etc/localtime alongside /etc/timezone

[Mark Hatle]

On 8/31/12 11:01 AM, Richard Purdie wrote:
> On Fri, 2012-08-31 at 15:29 +0100, Phil Blundell wrote:
>> On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
>>> As far as I know, only Intel have ever expressed any real interest in
>>> having this feature work.  My recollection is that there are some
>>> supposed "carrier grade" systems where this is, for whatever reason, a
>>> requirement.
>>
>> None of the carrier-grade people (or indeed any others) seem to have
>> spoken up in favour of a separate /usr in the past 3 days or so, which
>> does rather suggest that nobody actually cares about it.
>>
>> Maybe the TSC would like to reconsider whether this is in fact a
>> worthwhile thing to go on trying to support in oe-core or whether it
>> should just assume that / and ${prefix} will be the same filesystem.
>
> I think the people in question are at a conference at the moment and
> dealing with a few issues so they fact they haven't spoken up doesn't
> surprise me.

As Richard mentioned, a lot of folks were at a conference last week and with the 
holiday (in the US) over the weekend were not around to reply before.

> I'm fine with merging the symlink change. As others have mentioned, if
> it is an issue, a script to turn the links into copies can be written
> relatively easily.

Frankly, I'm an advocate of the split, and I'm in favor of the symlink change. 
A dangling link is fine for a non-criticial component like a timezone file.  If 
the system attempts to get the time, it will simply fall back to GMT, which to 
me is acceptable on embedded systems.

> I don't think dropping support for / and ${prefix} makes sense as long
> as it doesn't excessively hurt us. It is up to users to step up and help
> maintain the use cases they care about and so far, they have done this.
> So I think the position the TSC took is the correct one. Certainly we
> can revisit it but its not going to stop this patch going in for
> example.

Again, I agree with this.

At Wind River we've been following up and sending patches.  The issue is that we 
(OE) need to keep reviewing them and determining if they continue to make sense 
or not.  If we get into a situation where we've moved everything from /usr to /, 
it's pretty clear it no longer makes sense!  However, we're still far from the 
point.

initramdisk (from the comments to the links Khem sent out) is certainly a 
primary issue, but not the one I've been focused on in the past...

A number of devices that I've worked with do something -similar- to the ramdisk 
for early booting.  Boot order becomes:

firmware/bootloader -> kernel -> [small] rootfs mount (RO) -> run init

init -> module loading -> setup -> 'late' udev config -> mount filesystems 
(/usr) -> 'early' udev config

(late udev is running the daemon and watching for hotplug events, early udev is 
what triggers device creation behaviors.  The orders are switched both for 
performance, and because other then plugable devices -- the device tree is more 
or less static from one boot to the next, so our root has it pre-seeded...)

Many of the devices also have a validation and restoration system on root as 
well, that is performed by the setup step.  If the validation fails, then 
corrective actions can be taken to "fix" the system.  The / is always a RO 
system.. the device may contain more then one '/' to allow for upgrades, but the 
active one is always RO to avoid various potential problems.

The more software that gets put onto the system, the harder it will be to do 
field upgrades w/o a reboot.  (Since we don't want to allow / to change.)

Keeping the root small makes for a quicker boot, smaller set of partitions, and 
easier restoration on failure in my experience.

---

Again, if creating split systems no longer makes sense, I'm not against dumping 
the code..  I am going to be monitoring our customers, as much as I'm able, over 
the next 6 months -> year and seeing if anyone is doing this type of split 
anymore.. if they're not.. then we (OE) may, justifiably, abandon this behavior.

--Mark

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>