On Mon, 22 Dec 2014, Matthew Knepley wrote: > On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <[email protected]> wrote: > > > > > > In the past we've been not particularly supportive of getting PETSc in > > Linux package systems, in fact we've been a bit antagonistic. We should > > change this. > > > I have the same objection as before, namely that many of our users want > extra packages. Moreover, > even the ones that start with a plain vanilla installation often want to > add packages later.
I think extra packages would not be a problem. Basically the model would be: - package all dependent packages - build petsc with all such dependent packages. Variants would be a problem. Some packaging systems support it for major packages [for ex: mpich vs openmpi, mpich-hdf5, openmpi-hdf5]. In PETSc case - we might have issues with some of the variants we support [real, complex, 64bit indices etc..] But even if we can't support all variants - just getting some of them available for users via packagemanagers would be an improvement. [for the variants that linux packages don't support - one would have to install from source - which is the current mode anyway] > Thus, I could see us being distributed by a package manager IF we > retained the ability to reconfigure and rebuild. I would like the > packaged version to retain all the configure stuff and ARCH > directory so that a user can call the reconfigure script with extra > arguments and rebuild the package themselves. I think the general mode is for 'packagers' interested in packaging petsc [for ex: Sean for MacPorts] - to package and to some extent support the package. If I understand Barry's note - we should make it easier for such interested folks to package PETSc. Satish
