[petsc-dev] [Mike McQuaid] Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science (#23598)
Jed Brown
jed at jedbrown.org
Sun Feb 25 21:57:07 CST 2018
"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.
More information about the petsc-dev
mailing list