If you are doing development in a team setting , using Debian ' s packages will always be inferior to letting stack do it . It really depends , I guess . The usual operating mode of Stack that ' scommonly used i . e . not the Dockerbased one does an imperfect job athandling your GHC installation let me elaborateThis is a result of conflating two concerns , namely buildtool andsystem package management . I don ' t use a buildtool to install what Iconsider system tools , and in my opinion , a compiler or an editor issuch a systemwide installed tool . Only when I ' m actually working onthe compiler proper I tend to keep it in $. Then there ' s otherkind of team settings you ' re probably not referring to , such asstudent labs where you don ' t want every student ' s $ on a centralserver to take up disk space keeping redundant copies of GHCinstallations . In any case , it would require Stack to reimplement a lot offunctionality of real system package management tools which have seenyears of development and finetuning to get it perfected , and thosestill keep evolving and have accumulated a big ecosystem of existingtooling you ' d lose out on . And btw , calling tools like apt doing manual dependency managementseems a bit absurd to me , as those tools are in fact doing automaticdependency resolution which is quite comparable to what stack orcabal do , except for system packages rather than Haskell packages except those that are systempackaged . A few of the things Stack would need to address on Linux to be on parwith apt in case I got something wrong , let me apologize inadvance Stack is quickly progressing , so I can ' t always keep up withall latest developments Keep track and manage installation of dependencies of GHC c compiler , c libraries , etc , including interdep compatibility constraints . Handle uninstallation and handle dependency deinstallation recursively Handle updating GHC when security fixesupdates appear note that Linux distributions usually backport critical fixes to GHC versions as upgrading from e . g . GHC 7 . 8 . 3 7 . 8 . 4 would break binary compatibility Handle automatically updatingreinstalling GHC when you change something in the environment which requires this e . g . when the C compiler starts defaulting to PIE or when e . g . the system gets upgraded and the c libraries GHC relies on e . g . libgmp or libc change in such a way that makes it desirable to have GHC recompiled against the new so e . g . the RTS or integergmp can make use of more optimised entry points in libgmp or libc . There are tools and facilities for apt as well as other package mgmt systems to centrally distribute and manage software updates to keep the work environments in team settings synchronised automatically . That being said there is a way out Stack can have its cake and eatit to i . e . be convenient for users and principled at the sametime , if it would cooperate with the apt system management moretightly . I . e . let each tool handle the domain it ' s best at . apt forsystem packages , stack for haskell packages . Was I able to make you reconsider your position on Debian packagemanagement being always inferior to letting Stack handle it instead ?