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.

Michael



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to