[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