Skip to content
Snippets Groups Projects

Safety concerns with recursive deletion and XDG dirs

    • Open Issue created by Julian Ospald @maerwald
    1. Recursive deletion is currently done for ~/.ghcup/ghc/<ver>/. We could instead record all files and have a proper deletion.
    2. What to do with ~/.ghcup/bin files is another question, especially when XDG dirs are enabled (we don't have a guarantee we won't delete non-ghcup installed files if there are name clashes).

    This could easily grow in complexity though, because we don't want to turn ghcup into a package manager.

    Wrt 2. we could also just avoid using ~/.local/bin and instead use ~/.local/share/ghcup/bin, because the former is not (yet) in the XDG standard: https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/63

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Julian Ospald added typeimprovement + 1 deleted label

      added typeimprovement + 1 deleted label

    • Julian Ospald changed the description

      changed the description

    • Julian Ospald mentioned in merge request !49 (merged)

      mentioned in merge request !49 (merged)

    • Anton Latukha
      Anton Latukha @Anton-Latukha ·
      Contributor

      The GHCUP has a limited number of apps it installs, and them share a pretty strict pattern:

      ls ~/.local/bin

cabal -> cabal-3.2.0.0*
cabal-3.2.0.0*
ghc -> ../share/ghcup/ghc/8.8.4/bin/ghc*
ghc-8.8 -> ../share/ghcup/ghc/8.8.4/bin/ghc*
ghc-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/ghc*
ghci -> ../share/ghcup/ghc/8.8.4/bin/ghci*
ghci-8.8 -> ../share/ghcup/ghc/8.8.4/bin/ghci*
ghci-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/ghci*
ghc-pkg -> ../share/ghcup/ghc/8.8.4/bin/ghc-pkg*
ghc-pkg-8.8 -> ../share/ghcup/ghc/8.8.4/bin/ghc-pkg*
ghc-pkg-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/ghc-pkg*
ghcup*
haddock -> ../share/ghcup/ghc/8.8.4/bin/haddock*
haddock-8.8 -> ../share/ghcup/ghc/8.8.4/bin/haddock*
haddock-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/haddock*
haskell-language-server-8.10.1 -> haskell-language-server-8.10.1~0.6.0*
haskell-language-server-8.10.1~0.6.0*
haskell-language-server-8.10.2 -> haskell-language-server-8.10.2~0.6.0*
haskell-language-server-8.10.2~0.6.0*
haskell-language-server-8.6.4 -> haskell-language-server-8.6.4~0.6.0*
haskell-language-server-8.6.4~0.6.0*
haskell-language-server-8.6.5 -> haskell-language-server-8.6.5~0.6.0*
haskell-language-server-8.6.5~0.6.0*
haskell-language-server-8.8.2 -> haskell-language-server-8.8.2~0.6.0*
haskell-language-server-8.8.2~0.6.0*
haskell-language-server-8.8.3 -> haskell-language-server-8.8.3~0.6.0*
haskell-language-server-8.8.3~0.6.0*
haskell-language-server-8.8.4 -> haskell-language-server-8.8.4~0.6.0*
haskell-language-server-8.8.4~0.6.0*
haskell-language-server-wrapper -> haskell-language-server-wrapper-0.6.0*
haskell-language-server-wrapper-0.6.0*
hp2ps -> ../share/ghcup/ghc/8.8.4/bin/hp2ps*
hp2ps-8.8 -> ../share/ghcup/ghc/8.8.4/bin/hp2ps*
hp2ps-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/hp2ps*
hpc -> ../share/ghcup/ghc/8.8.4/bin/hpc*
hpc-8.8 -> ../share/ghcup/ghc/8.8.4/bin/hpc*
hpc-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/hpc*
hsc2hs -> ../share/ghcup/ghc/8.8.4/bin/hsc2hs*
hsc2hs-8.8 -> ../share/ghcup/ghc/8.8.4/bin/hsc2hs*
hsc2hs-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/hsc2hs*
runghc -> ../share/ghcup/ghc/8.8.4/bin/runghc*
runghc-8.8 -> ../share/ghcup/ghc/8.8.4/bin/runghc*
runghc-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/runghc*
runhaskell -> ../share/ghcup/ghc/8.8.4/bin/runhaskell*
runhaskell-8.8 -> ../share/ghcup/ghc/8.8.4/bin/runhaskell*
runhaskell-8.8.4 -> ../share/ghcup/ghc/8.8.4/bin/runhaskell*

      So:

      readlink haddock | grep ghcup
../share/ghcup/ghc/8.8.4/bin/haddock
      Edited by Anton Latukha
    • Anton Latukha
      Anton Latukha @Anton-Latukha ·
      Contributor

      After thinking about it - maybe the PATH expansion is indeed the way, since Stack installs in the same folder, but that probably is up to user, but also as a result would complicate GHCUP handling.

      PATH expansion is already drastic and a default workaround, there are already too much package managers that extend the PATH, so one more or less - there is no difference, and PATH expansion seems to be the way package managers overcome issues.

      What I see that is more beneficial to give people - is saving the config state in the XDG_USER_CONFIG and support the recreation of the state. So people can backup or share the config - and restore/receive config and arrive at the same/similar configuration.

      BTW, ~/.local/bin is not an XDG specification - it is a people-born spin on it. I think XDG creators knew what they are doing - they probably understood that executable placement would be solved/most simply to solve with PATH rewriting in the foreseeable time.

      So ~/.local/bin is not XDG spec in any case shape or form, and on request, you can point people into that, and that it is most probably deliberate.

    • Julian Ospald
      Julian Ospald @maerwald ·
      Author Owner

      What I see that is more beneficial to give people - is saving the config state in the XDG_USER_CONFIG and support the recreation of the state. So people can backup or share the config - and restore/receive config and arrive at the same/similar configuration.

      I really don't know what that means. But ghcup won't recreate anything like nix.

      So ~/.local/bin is not XDG spec in any case shape or form, and on request, you can point people into that, and that it is most probably deliberate.

      There is a PR. See the link in my first post.

      My concern is that ghcup makes assumptions about binary names. I haven't reviewed all of it, but if you had a file ~/.local/bin/foo-ghc-10 that was from a completely different program, I couldn't say of the top of my head whether it will confuse ghcup or not.

    • Julian Ospald
      Julian Ospald @maerwald ·
      Author Owner

      I just hit a problem with cabal-hie binary in XDG mode... it thinks hie is a version and it was installed by ghcup. So this is already a name clash.

    • Julian Ospald changed title from Avoid recursive deletion to Safety concerns with recursive deletion and XDG dirs

      changed title from Avoid recursive deletion to Safety concerns with recursive deletion and XDG dirs

    • Julian Ospald mentioned in merge request !101 (merged)

      mentioned in merge request !101 (merged)

    • Julian Ospald added typediscussion label

      added typediscussion label

    Please register or sign in to reply