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

Jed Brown jed at jedbrown.org
Sun Feb 25 22:07:58 CST 2018

"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).  It's a package manager despite conspicuous
missing features.

More information about the petsc-dev mailing list