On Wed, 17 Apr 2019, Smith, Barry F. via petsc-users wrote: > This is fine for "hacking" on PETSc but worthless for any other package. > Here is my concern, when someone > realizes there is a problem with a package they are using through a package > manager they think, crud I have to > > 1) find the git repository for this package > 2) git clone the package > 3) figure out how to build the package from source, is it ./configure, cmake, > what are the needed arguments,... > 4) wait for the entire thing to build > > then I can go in and investigate the problem and provide and test the fix via > a pull request. Heck I'm not going to bother. > > Thus a lot of potential contributions of small fixes that everyone in the > community would benefit from are lost. This is why, for > me, an ideal HPC package manager provides a trivial process for providing > fixes/improvements to other packages. > > For example Sajid could have easily figured out the VecView_MPI_HDF5() bug > and provided a fix but just the hassle of > logistics (not ability to solve the problem) prevented him from providing the > bug fix to everyone rapidly.
Even without spack and multiple packages - this is not a easy thing to do. For ex: most of our users install petsc from tarball. And if they find a bug - they have to go through similar complicated process [create a bitbucket account, get a fork - learn the petsc PR process - make a PR etc]. With spack - I stick to the usual process - and don't get bogged down by 'spack' support for this process. If I see a breakage - I do 'spack build-env package [this has its own issues] - attempt a fix - get it first working with a spack build. [Alternative is to just edit the package file to get my fix - if its a patch I can find] Once I have it working [the major issue is taken care off]. Then I have a diff/patch and then worry about how to submit this diff/patch to upstream. Sure its a multi step model - and has many trip points. But is not that our current petsc only model doesn't have any. Satish