Changes between Version 8 and Version 13 of Ticket #22510


Ignore:
Timestamp:
04/05/18 15:31:22 (2 years ago)
Author:
embray
Comment:

Some new explanation of the work planned for this ticket, so I can break it up into multiple smaller chunks.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #22510

    • Property Status changed from needs_review to needs_work
    • Property Dependencies changed from #22509 to
    • Property Branch changed from u/embray/build/uninstall to
    • Property Commit changed from 620287c2606f30fe3ea5623c87015dbc1b73817c to
    • Property Milestone changed from sage-8.1 to sage-8.2
  • Ticket #22510 – Description

    v8 v13  
    1 Currently spkg uninstallation is handled in an ad-hoc manner.  Many packages contain some rough uninstallation steps in their `spkg-install` scripts (to be run, for example, when upgrading/reinstalling a package).  But these are often imprecise and not thorough (though maybe still worth keeping where they already exist, as I will explain below).  Here are a few proposals for improving package uninstallation (which is useful even for required packages, such as in the case of upgrading them):
     1Currently spkg uninstallation is handled in an ad-hoc manner.  Many packages contain some rough uninstallation steps in their `spkg-install` scripts (to be run, for example, when upgrading/reinstalling a package).  But these are often imprecise and not thorough (though maybe still worth keeping where they already exist, as I will explain below).
     2
     3
     4=== implementation ===
     5
     6* #22509 - most packages are now installed with staged installation (i.e. DESTDIR installation), which enables creating a manifest of all files installed by that package (minus files created by the package's `spkg-postinst` script).  This is mostly working now for almost all packages (see #24024).
     7
     8* #????? - add an spkg-uninstall script: this would read the file manifest for a package (if it exists) and remove those files from `$SAGE_LOCAL`--thus uninstalling the package thoroughly and precisely.
     9  * #????? - support legacy uninstallers: many existing spkgs have steps in their `spkg-install` for "uninstalling" that package--mostly just removing a few key files associated with the package (executables and libraries), but was rarely complete.  However, some of these legacy uninstall steps are still necessary for properly building the package if the package has not already been uninstalled.  This is an issue for the new system insofar as we want upgrades from older versions of Sage to work, so the legacy uninstallers are still needed at least for one upgrade, if uninstalling a package that doesn't have a proper file manifest.  Since these steps are no longer needed in the `spkg-install` (in fact ideally `spkg-install` should not modify `$SAGE_LOCAL` at all, we move those steps into a separate `spkg-legacy-uninstall` script which is run only when uninstalling a package that is missing its file manifest.
     10    * #????? - once this infrastructure is in place there are several packages with 'legacy uninstallers' that would need to be updated.
     11  * #????? - also add support for an `spkg-postrm` script that would be the complement to a `spkg-postinst` script, and may clean up files generated by a package that are not part of the package's file manifest
     12
     13
     14=== old design discussion ===
     15Here are a few proposals for improving package uninstallation (which is useful even for required packages, such as in the case of upgrading them):
    216
    317* For all installed packages, maintain lists of the files installed by those packages.  For this, something like #22509 is a prerequisite. This list could even go into the `$SAGE_LOCAL/var/lib/sage/installed/` files we already have.  Uninstalling a package would consist primarily of removing all files in this list.  It would also remove directories that are left empty after all files are removed.
     
    721* Add support for an optional `spkg-legacy-uninstall` script.  This would contain whatever commands the `spkg-install` scripts currently perform for uninstall.  This would only be run when the installed file list described in the first bullet point is unavailable (e.g. for backwards compatibility when upgrading to this new system for the first time).  This feature could maybe be removed entirely later, but would be good to add at first and keep around for a while.
    822
    9 The new process for upgrading / reinstalling a package could b (especially if more progress is made toward supporting #21726 in all spkgs):
     23The new process for upgrading / reinstalling a package could be (especially if more progress is made toward supporting #21726 in all spkgs):
    1024
    1125    1. Build