FS#13998 - Implement --clean to remove all traces of a package

Attached to Project: Pacman
Opened by Nezmer (Nezmer) - Saturday, 28 March 2009, 20:52 GMT
Last edited by Dan McGee (toofishes) - Saturday, 28 March 2009, 21:15 GMT
Task Type General Gripe
Category General
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.2.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No

Details

Summary and Info:
I've been using Arch for more than 5 months . The only problem I encountered that wasn't trivial to fix was with CUPS . I tried downgrading packages , removing with 'pacman -cnsu' and reinstalling and finally rebuilding packages . Nothing actually worked . It turned out I had to remove /etc/cups directory to get rid of all traces of CUPS . That actually worked .

The files in '/etc/cups' (not just the contents) varies from user to user and they can change continuously . When you remove cups (even with --nosave) , those files will remain in the system .

What I'm suggesting here is to implement 'pacman -R --clean' (replace clean with any suitable word) to remove all traces of a package . What '--clean' should do can be determined in the '.install' file for flexibility .

Another example is '/usr/lib/oss' . This directory is owned by OSS (Open Sound System) . Currently , this part is included in the .install' file :
post_remove() {
echo
echo "-------------------------------------------------------------"
echo " Open Sound System was now removed, and the ALSA kernel"
echo " modules were restored."
echo
echo " Please note that OSS stores some of its configuration files"
echo " at /usr/lib/oss. If you don't plan to use OSS anymore, you"
echo " can remove this directory."
echo "-------------------------------------------------------------"
/bin/true
}

I know I should provide more real-life examples where this option can solve general problems but that's all I have . It's just a suggestion so feel free to ignore it .

""Sorry for my poor English""

Steps to Reproduce:
Major upgrade to a package breaks something because some files not owned by the package but created by running it are not compatible with the new version .
This task depends upon

Comment by Dan McGee (toofishes) - Saturday, 28 March 2009, 21:14 GMT
This is not at all a trivial or easily described problem. In fact, it is very similar to  FS#13932  in that there is not always a perfect option to take- sometimes an empty directory is in fact required there, just as here we may end up blowing away files that a user wanted to keep.

In short, if pacman doesn't know about the file, we aren't going to touch it. It is just too risky.
Comment by Nezmer (Nezmer) - Saturday, 28 March 2009, 21:26 GMT
I see how It's not trivial .

My initial thought was that the option should be used in extreme cases where the user wants to restore to the state before the package was ever installed . The option should not remove directories or files known to be used by more than one package .

Anyway , I understand how hard implementing this feature would be . I just wanted to share the thought .

Thank you for replying and explaining the complexity of the situation .
Comment by Venky (venky80) - Thursday, 23 April 2009, 23:01 GMT
ya same thing happens with samba too, i think if this thing is solved pacman will be unbeatable...
I agree with Nezmer, user should be given option with warnings
Comment by Allan McRae (Allan) - Friday, 24 April 2009, 01:52 GMT
How about a script in pacman-contrib that identifies directories which only contains files that pacman does not know about? That could also solve  FS#11473 
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 29 May 2009, 04:22 GMT
Hi, i created a simple script to deal with files that pacman does not track (of course an .INSTALL script can track some of these files)

#!/bin/bash

IGNORE="^/lib/modules|^/usr/local|^/usr/src|^/usr/share/mime|^/usr/share/texmf-var"
SEARCH="/bin /etc /lib /opt /sbin /usr"

# search for regular files
comm -2 -3 <(find $SEARCH -type f | sort -u | egrep -v $IGNORE) <(pacman -Qlq | awk '$2 !~ "/$" {print $2}' | sort -u)

# search for symlinks
# comm -2 -3 <(find $SEARCH -type l | sort -u | egrep -v $IGNORE) <(pacman -Qlq | awk '$2 !~ "/$" {print $2}' | sort -u)
Comment by Allan McRae (Allan) - Friday, 29 May 2009, 04:39 GMT Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 29 May 2009, 04:51 GMT
oh great! "a rain of scripts": I just posted my version in the most recent thread ;) Thanks.
Comment by Venky (venky80) - Wednesday, 03 June 2009, 14:25 GMT
where did you post your script? does it need root access to run?
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 03 June 2009, 17:27 GMT
@Venky, above in the comment. Just show files only, so depending of your perms in filesystem, does not need CAP_DAC_READ_SEARCH at all.
Comment by Allan McRae (Allan) - Saturday, 09 February 2013, 05:27 GMT
If anyone every wants to look at this, here is what I would be happy with...

Add a "cleanup=()" variable in the PKGBUILD for known files the software generates and those files can be removed with the package.
Comment by Ashley Whetter (AWhetter) - Wednesday, 10 July 2013, 14:51 GMT
A clean up variable could be open to abuse though. It's probably not such a problem for official packages because they'll go through [testing] first and (hopefully) we can trust official maintainers ;), but there will be people who will blindly install AUR packages that might have '/usr' in the cleanup array.

Also you'd need to consider changes between application versions, where the new version might not use an old directory any more. You'd have to have a 'cleanup_upgrade' array as well probably.

Also what if a user doesn't want the files/folders to be deleted. If I'm switching from chromium to chromium-stable I might not want ~/.cache removed (as an example) because I'm just switching to a different flavour. Same could apply to switching between regular and -git packages.

To me it all seems a bit complex and risky for something fairly trivial, as much as I hate having old files hanging around. Maybe adding an option to pacman to do what the above scripts do, or including a script as pacman-clean (or whatever) to the pacman package, or just having that script in a package separate to pacman altogether (even if it's in the AUR and mentioned on the wiki somewhere)?
Comment by Allan McRae (Allan) - Sunday, 31 January 2016, 04:49 GMT
RPM has ghost file support for this. FS#47908

Loading...