[petsc-dev] Sean is going to love this

[Satish Balay]

On Mon, 22 Dec 2014, Matthew Knepley wrote:

> On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <bsmith at mcs.anl.gov> 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