Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NixOS/nixpkgs
base: 8460769e88eb
Choose a base ref
...
head repository: NixOS/nixpkgs
compare: bdf390f9959d
Choose a head ref
  • 2 commits
  • 4 files changed
  • 2 contributors

Commits on Apr 26, 2018

  1. cpython: don't use lchmod() on Linux, fix w/musl

    upstream issue:
    https://bugs.python.org/issue31940
    
    There are two PR's proposed to fix this,
    but both seem to be stalling waiting for review.
    
    I previously used what appears to be the favored
    of the two approaches[1] to fix this,
    with plan of keeping it musl-only until PR was merged.
    
    However, while writing up a commit message
    explaining the problem and why it needed fixing...
    
    I investigated a bit and found it increasingly
    hard to justify anything other than ...
    simply not using lchmod.
    
    Here's what I found:
    * lchmod is non-POSIX, seems BSD-only these days
    * Functionality of lchmod isn't supported on Linux
      * best scenario on Linux would be an error
    * POSIX does provide lchmod-esque functionality
      with fchmodat(), which AFAICT is generally preferred.
    * Python intentionally overlooks fchmodat()[2]
      electing instead to use lchmod() behavior
      as a proxy for whether fchmodat() "works".
      I'm not sure I follow their reasoning...
    * both glibc and musl provide lchmod impls:
      * glibc returns ENOSYS "not implemented"
      * musl implements lchmod with fchmodat(),
        and so returns EOPNOTSUPP "op not supported"
    * Python doesn't expect EOPNOTSUPP from lchmod,
      since it's not valid on BSD's lchmod.
    * "configure" doesn't actually check lchmod usefully,
      instead checks for glibc preprocessor defines
      to indicate if the function is just a stub[3];
      somewhat fittingly, if the magic macros are defined
      then the next line of the C source is "choke me",
      causing the compiler to trip, fall, and point
      a finger at whatever is near where it ends up.
      (somewhat amusing, but AFAIK effective way to get an error :P)
    
    I'm leaving out links to threads on mailing lists and such,
    but for now I hope I've convinced you
    (or to those reading commit history: explained my reasons)
    that this is a bit of a mess[4].
    
    And so instead of making a big mess messier,
    and with hopes of never thinking about this again,
    I propose we simply tell Python "don't use lchmod" on Linux.
    
    [1] python/cpython#4783
    [2] https://github.com/python/cpython/blob/28453feaa8d88bbcbf6d834b1d5ca396d17265f2/Lib/os.py#L144
    [3] https://github.com/python/cpython/blob/28453feaa8d88bbcbf6d834b1d5ca396d17265f2/configure#L2198
    [4] Messes happen, no good intention goes unpunished :).
    dtzWill committed Apr 26, 2018
    Copy the full SHA
    b11f3bc View commit details
    Browse the repository at this point in the history
  2. Merge pull request #39517 from dtzWill/fix/python3.x-musl-lchmod

    cpython: don't use lchmod() on Linux, fix w/musl
    dtzWill committed Apr 26, 2018
    Copy the full SHA
    bdf390f View commit details
    Browse the repository at this point in the history