On Apr 8, 2012, at 1:57 PM, Michael Hanke wrote: > Package: condor > Version: 7.7.5~dfsg.1-2 > Severity: important > > The Condor package removes a couple of log/runtime files during package > removal that probably should not be removed. This code bit is executed > when the package gets removed: > > for dlabel in CRED_STORE_DIR LOCAL_UNIV_EXECUTE EXECUTE LOCK LOG RUN > SPOOL; do > dname=$(condor_config_val $dlabel) > if [ $? -eq 0 ]; then > # should we rely on the configuration to be sane? > #rm -rf $dname > # better have some safety-net and only delete what > belongs to condor > # if we have a condor user at all > id -u condor > /dev/null 2>&1 && [ -d "$dname" ] && > find $dname -type f -user condor -group condor -delete || true > # try getting rid of the directory as well, but do not > fail if there > # were left-overs > rmdir $dname || true > fi > done > > If at all, this should be done when the packages is purged. Right now > Condor looses all its logfiles when an admin (temporarily) removes > Condor from a system -- if I would be that admin, I'd hate it. > > However, this cleanup function cannot simply be moved into the postrm > script, as it relies on Condor's own configuration mechanism > (condor_config_val) to determine where the corresponding files actually > are -- this functionality is not available during postrm, as all condor > tools are already gone by that time. > > I see two possibilities: 1) do not remove logs/runtime data -- not > desirable as the package should not leave unnecessary cruft behind after > having been purged. > > Or 2) Make an attempt to remove this data from the "standard" location > (/var/...), if it is there. If it is not there, just ignore it. This is > not perfect, but should work in many cases -- especially for novice > Condor users. Experts would be more likely to know what to do anyway. > > Option 2) seems to be the better one. However, if the package can't > deal with "non-standard" runtime data locations, it would be logical to > remove the package's ability to place the data into non-standard > locations also -- reduces complexity as well. > > I'd be happy to get feedback on this one and implement the result in the > 7.7.6 package update.
I like option 2, removing the files from the standard locations during a purge. If we want to continue allowing the location to be changed during package installation, the installer could save the non-standard location in a file that the purge code could consult. Then the purge code would delete that file last. This reminds me that we haven't talked about the debconf configuration questions. We should do that in the near future. +--------------------------------+-----------------------------------+ | Jaime Frey | I used to be a heavy gambler. | | jf...@cs.wisc.edu | But now I just make mental bets. | | | That's how I lost my mind. | +--------------------------------+-----------------------------------+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
