We discussed at DebConf the need for a property that removes propellor from a host. It would run itself at the end of the spin. It needs to nuke /usr/local/propellor. To what extent can it remove propellor's build dependencies? I can see two problems to be resolved before writing any code.
There is no standard way to remove cabal and stack packages from
/rootwithout potentially nuking stuff the user wants to keep. So maybe the property should remove only OS packages? I.e. best used onOSOnlyhosts/chroots.What if another property on the host installs some or all of those build dependencies? This property would be cancelled out by the unpropellor property. Maybe properties that install packages need to set info about the packages that are meant to remain installed?
The unpropellor property could just nuke /usr/local/propellor and leave it at that. But then the sbuild module would need to maintain a list of propellor's build deps to remove from the newly created chroot, which is a third copy of the list..
--spwhitton
All this property needs to do when
inChrootis True is unmount anything bound below /usr/local/propellor and delete that directory, which should be empty.OF course it's harder to implement it for use outside a chroot, but a property that works in a chroot would be enough for sbuild and would be a reasonable start.
I don't think there's any sane way to remove cabal and stack cruft without deleting it all.
Seems like to uninstall the build deps, it would be useful to get the build deps installed in the first place in a way that makes
apt-get autoremoveable to remove them. Currently, Bootstrap.depsCommand hardcodes a list of debian packages. It could instead just install propellor.deb, which depends on the same stuff, so the build deps get autoremoved after propellor is removed.But, different versions of the propellor package might have different deps than the version of propellor being bootstrapped.