On Wed, Nov 6, 2019 at 7:58 AM Simon King <simon.k...@uni-jena.de> wrote: > > On 2019-11-05, E. Madison Bray <erik.m.b...@gmail.com> wrote: > > The generated file `build/make/Makefile` is output by the > > `./configure` script. In fact, that's its main purpose. When > > switching branches in this case the best thing to do is to re-run > > `./configure`. > > Concerning the original question how to uninstall stuff: In principle it > should be possible to cleanly uninstall p_group_cohomology, because it > consists of one autotoolized and one pip-installed sub-package.
That's not the issue here; the issue is that when you uninstall the package files, some of the build system still needs to be reset. This is indeed a problem, and there should be a better way to handle what packages are or are not installed without necessarily having to re-run configure, but I haven't given much thought to it. > However, I heard rumours that in order to make a Sage optional package > uninstallable, one needs some new script analogous to spkg-install. > > Can someone give me a pointer on what should be done in that script and > what tools (sdh_*) are available for it? That's not quite accurate. In general you do *not* need any additional scripts, with some exception. These packaging guidelines still need better documentation, but essentially you need to make sure the package is built for what is referred in GNU standards as a "DESTDIR install" [1]. This means that the package is built for installation to some particular prefix (e.g. `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be *installed* with some additional path (the "DESTDIR") prepended to the prefix. This is similar to providing an alternate root (e.g. prefix is appended to DESTDIR instead of just "/"). This allows the package to be installed to a temporary "staging" area that makes it easy, in an otherwise agnostic way, to see exactly what files are going to be installed by the package so that we can generate a manifest from it. Any packaging using standard autoconf tools supports DESTDIR. Most CMake packages do as well I think but I forget if there's something special one has to do. Pip also supports this. Packages with weird custom build systems may need to be patched or worked around in other ways to support this, but fortunately there are not too many like that in Sage anymore. In some cases it is necessary to perform additional package installation steps more complicated than just copying files. In this case one can write an spkg-postinst script to perform such steps. This is mentioned here [2]. However, if an "spkg-postinst" installs or creates any files in $SAGE_LOCAL, although not necessarily required in all cases it might be good to uninstall those files as well, in which case one needs to write an "spkg-postrm" script. Normally this isn't necessary though, and there are only a few examples of this in use.* [1] https://www.gnu.org/prep/standards/html_node/DESTDIR.html [2] https://doc.sagemath.org/html/en/developer/packaging.html#build-and-install-scripts * One bug I am aware of in our packages is that there is a common file "share/info/dir" which some packages that support "info" modify/append to during installation. When using DESTDIR install this means a new share/info/dir file gets created, and then copied over any existing "share/info/dir". To handle this properly requires postinst/postrm scripts which handle this infodir for any packages that use it. I had a branch a long time ago that took care of this but it was part of a larger patchbomb and never got merged I think. However, it's not a high-priority issue; I don't think a lot of people are using `info` or someone would have complained by now, maybe... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34ZmRQTJegm5f2zOVvFjOhhncQinRaTvj6SwFiVax4xQkg%40mail.gmail.com.
