[petsc-dev] [Mike McQuaid] Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science (#23598)

[Smith, Barry F.]

> On Feb 25, 2018, at 10:07 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> 
>>> On Feb 25, 2018, at 9:57 PM, Jed Brown <jed at jedbrown.org> wrote:
>>> 
>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>> 
>>>>> On Feb 25, 2018, at 9:46 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>> 
>>>>> Satish Balay <balay at mcs.anl.gov> writes:
>>>>> 
>>>>>> On Sun, 25 Feb 2018, Lawrence Mitchell wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 25 Feb 2018, at 21:13, Jed Brown <jed at jedbrown.org> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The try part of that commit (around os.remove) is necessary.  Also,
>>>>>>>> "rmdir -p" provides a useful semantic in this context, but needs to be
>>>>>>>> implemented manually in Python (or I don't know where that functionality
>>>>>>>> is available in the standard library).
>>>>>>> 
>>>>>>> shutil.rmtree
>>>>>> 
>>>>>> I think [in uninstall script] - we want to delete dirs only if the dir
>>>>>> is empty.  [if not empty - it could contain files installed by a
>>>>>> different package - as its common to install multiple packages in the
>>>>>> same prefix]
>>>>> 
>>>>> Yeah, "rm -r" is much different from "rmdir -p".
>>>>> 
>>>>>> Also - thinking about it - its not clear if we can really do a proper
>>>>>> uninstall - esp with --download-packages.
>>>>>> 
>>>>>> Previously - 'make install' would also install the downloaded packages
>>>>>> and we kept track of them for the uninstall script. But now - we let
>>>>>> each package do its own 'make install' to the prefix location. But we
>>>>>> don't have an 'uninstall' option for these externalpackages. [I don't
>>>>>> know if any of them provide 'make uninstall' feature]
>>>>> 
>>>>> PETSc --download-* is a package manager, albeit very crufty (though it
>>>>> gets the job done).  Basically all package managers function by
>>>>> installing with a private DESTDIR, bundling up the result, then
>>>>> unpacking into the target.
>>>> 
>>>>  That's not how PETSc's works. It tells the each package the final prefix and each package installs into that location directly.
>>> 
>>> That's just because PETSc's package manager is kinda crappy because
>>> nobody wants to admit that it really is a package manager.  If uninstall
>>> is to be a thing at all, then it's definitely the way to go.
>> 
>>   We use to do it the "package manager way" but I think so many packages couldn't be DESTDIRed and then installed that we went with the install directly approach.
> 
> Many/all of those packages are available in Debian or Conda or Homebrew, etc.
> 
>>   I think it is wrong to call PETSc's thing a package manager. It is and always has been only a package installer, it is hopeless at managing packages.
> 
> And yet we're talking about uninstall and we also have support for
> upgrading them (except that it doesn't clean up the old version and thus
> isn't very reliable).

   Huh, it has support for upgrading them? 

>  It's a package manager despite conspicuous
> missing features.