Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean Python cache in prerm only #6782

Draft
wants to merge 1 commit into
base: develop
Choose a base branch
from
Draft

Clean Python cache in prerm only #6782

wants to merge 1 commit into from

Conversation

legoktm
Copy link
Member

@legoktm legoktm commented Apr 14, 2023

Status

Ready for review

Description of Changes

We are currently cleaning the Python cache in the postinst and postrm, but that still leaves us with warnings from apt that non-empty __pycache__ directories couldn't be deleted.

This mimics what dh-python does, which is to run py3compile in the postinst (already doing) and run py3clean in the prerm.

During a fresh install, only the postinst is triggered to compile the cache.

During an upgrade, first the prerm runs, removing the cache, then the new version is unpacked, then postinst goes, recreating the cache.

Fixes #6743.

Testing

  • Set up a 2.5.1 prod/staging install
  • Run make build-debs with this PR,
  • Upgrade to the new 2.6.0~rc1 securedrop-app-code deb on the instance with sudo apt install ./securedrop-app-code....deb
  • Observe no dpkg warnings during upgrade
  • Check that /opt/venvs/securedrop-app-code/lib/python3.8/site-packages/passlib/ no longer exists
  • Look through one or two other dependencies in the venv, verify the __pycache__ folders were created and are owned by root.

Deployment

Any special considerations for deployment? Considered, see above for explanation.

Checklist

  • Configuration tests pass
  • I have written a test plan and validated it for this PR
  • These changes do not require documentation

We are currently cleaning the Python cache in the postinst and postrm,
but that still leaves us with warnings from apt that non-empty
`__pycache__` directories couldn't be deleted.

This mimics what dh-python does, which is to run py3compile in the
postinst (already doing) and run py3clean in the prerm.

During a fresh install, only the postinst is triggered to compile the
cache.

During an upgrade, first the prerm runs, removing the cache, then the
new version is unpacked, then postinst goes, recreating the cache.

Fixes #6743.
@legoktm legoktm added this to the 2.6.0 milestone Apr 14, 2023
@legoktm legoktm requested a review from a team as a code owner April 14, 2023 21:23
@legoktm
Copy link
Member Author

legoktm commented Apr 14, 2023

(just FYI I haven't actually tested this since I'm using my prod setup to test the other cron->systemd PR, but uh, it should work!)

@zenmonkeykstop zenmonkeykstop self-assigned this Apr 28, 2023
@zenmonkeykstop
Copy link
Contributor

Tested by:

  • setting up 2.5.2(current version) on prod VMs

  • building packages locally and installing using upgrade scenario (as opposed to dpkg)

  • no warnings observed during install

  • .../passlib still exists

  • spot-checking __pycache__ dirs, they do exist and are root-owned.

Copy link
Contributor

@zenmonkeykstop zenmonkeykstop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.../passlib still exists so test plan not passing.

@legoktm legoktm removed this from the SecureDrop 2.6.0 milestone May 15, 2023
@legoktm legoktm marked this pull request as draft May 25, 2023 19:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Empty dependency __pycache__ folders left behind on upgrade
2 participants