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

Smith, Barry F. bsmith at mcs.anl.gov
Sun Feb 25 22:03:11 CST 2018



> 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.

   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.

  Barry




More information about the petsc-dev mailing list