On Fri, 05 Aug 2011 13:31:11 -0700, Darren New wrote:

> On 8/4/2011 21:17, Jim Henderson wrote:
>> what he's seeing is part of the standard filesystem behaviour.
> 
> Nah. I can overwrite a config file, or I can write a new file and rename
> it to be the config file, and these are entirely different things on
> Linux. The package manager just happens to do the latter.

Sure, but he's describing the behaviour as a package manager behaviour, 
when in fact it's an OS/filesystem behaviour.

> The whole story is basically:
> 
> 1) We can't just fork, because glib and other libraries might have locks
> open, and in that case things with threads break, and we use threads.
> 
> 2) We can't just fork+exec, because if we exec, we get the new version
> of the executable which expects the new versions of files and it might
> not communicate well with the existing running processes.
> 
> 3) So instead we start a helper process to hold open all the old
> versions of files because that's the only way to keep them from being
> deleted once they're unlinked, and the package manager unlinks old
> versions of files. And stuff often breaks if we forget to make sure
> every file we might need gets versioned this way.

But that's not what he wrote, and in writing it the way he did, he got 
some things wrong.  <shrug>  It happens, but it's important to understand 
how he got them wrong so the above makes sense.

Jim

Post a reply to this message