[Distutils] Installing packages using pip

[Nathaniel Smith]

On Tue, Dec 8, 2015 at 7:10 PM, Ionel Cristian Mărieș
<contact at ionelmc.ro> wrote:
>
> On Wed, Dec 9, 2015 at 2:18 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> Just want to make sure that the actual semantics here are clear -- there's
>> nothing mysterious about the Unix semantics, and it's pretty easy to predict
>> what will work and what won't once you understand what's going on.
>
>
> You don't have any guarantees that running process won't try to use stuff
> from disk later on do you?  If it segfaults (and it does in my "general
> usecases") it's hard to debug - you got nothing conveniently on disk.

Yes, exactly: if a running process calls 'open' after a file has been
replaced then it gets the new file; if it calls 'open' before a file
has been replaced then it gets the old file (and keeps it until it
calls 'close', even if it's deleted or renamed-over in the mean time).

There's nothing intrinsically segfaulty about this, but sure, if you
write your program in such a way that it (a) opens a file while
running, and (b) segfaults if the file it wants to open is missing or
from the wrong version, then yeah, this will trigger that segfault.
Probably it would be better to write your program so that missing or
corrupted files produce a more controlled error rather than a
segfault, and it would then be more robust regardless of upgrade
issues, but I can certainly believe that such buggy programs exist.

> And
> no, "upgrading libc" is not a general usecase, it's just one of those few
> things that work because they were written in a very specific way, and you
> should not apply that technique in the general usecase.

It's the general technique that Linux systems always use when
upgrading executables and shared libraries, which are the cases that
Windows handles differently, so it's probably worth understanding, is
all.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org