The puphpet-release package properly tracks files deleted or moved from the puphpet.zip file and writes those changes into its release/ folder, but when we copy the composer-installed vendor/loadsys/puphpet-release/release/* files to ROOT/puphpet/, we only copy and don't fully "sync". That means deleted files in the release/ folder will still hang around in ROOT/puphpet.
We need to use a smarter mechanism that also removes old unnecessary files that have been deleted from our "upstream" provider.
This issue overlaps with the problem of preserving the generated ssh keys that are added to ROOT/puphpet/files/ssh/ during VM provisioning. These files need to remain in place through composer update executions, but would be purged by the process described above. This makes things very complicated as we'd need to special case JUST those files somehow in our composer installer script.
The best way to solve this is to convince the puphpet project to store the files/ subdirectory somewhere outside of the puphpet/ directory (same for the config.yaml file, in fact). This would make a clean separation between "vendor" files and user-customizable "config" files and our job would be downright simple.
The
puphpet-releasepackage properly tracks files deleted or moved from thepuphpet.zipfile and writes those changes into itsrelease/folder, but when we copy the composer-installedvendor/loadsys/puphpet-release/release/*files toROOT/puphpet/, we only copy and don't fully "sync". That means deleted files in the release/ folder will still hang around in ROOT/puphpet.We need to use a smarter mechanism that also removes old unnecessary files that have been deleted from our "upstream" provider.
This issue overlaps with the problem of preserving the generated ssh keys that are added to
ROOT/puphpet/files/ssh/during VM provisioning. These files need to remain in place throughcomposer updateexecutions, but would be purged by the process described above. This makes things very complicated as we'd need to special case JUST those files somehow in our composer installer script.The best way to solve this is to convince the puphpet project to store the
files/subdirectory somewhere outside of thepuphpet/directory (same for theconfig.yamlfile, in fact). This would make a clean separation between "vendor" files and user-customizable "config" files and our job would be downright simple.