You are not logged in.

#1 2020-05-09 09:30:00

vogu66
Member
Registered: 2020-05-09
Posts: 3

Pacman user files

Hello,

In the home directory there are a whole lot of files that are just per user configuration and data files from different packages. But those files are not deleted when packages are removed (mainly because they are 'per user' and I am not sure pacman would have the permission to delete them, I suppose). The thing is it is hard to clean up automatically when a lot of packages have non-trivial/non-standard folders or config files (e.g., I've got : ~/.zoom, ~/Wolfram, ~/.Wolfram, ~/config/kile-livepreview-okularpartrc, and so on).

So I've been looking in the how PKGBUILD are made and what pacman options there are, and I realized there is a way to get all system files from a package, there is the "backup" attribute in PKGBUILD, and there are ways to search for unowned files using (e.g. pacreport); but there is no way to search the user files, that are created when programs run -- to my knowledge, because they belong to the user and there is no list anywhere.

Thus maybe it would be interesting to add a property to the PKGBUILD, of what files and folders are or can be created by the program or by the user as options for the program, so that it would be possible to have a per user list of what has been there, for what package? And eventually maybe it would be possible to add a pacman option to list/remove what is unneeded for a specific user?

I suppose the list per user should have package versions that have been installed and a list of the files for that version, and when cleaning up the system would remove the files for deleted packages (and remove those from the list) as well as compare the different package versions to see if some files are no longer required (as well as remove the entries for old versions in the list).

It could also be used by utilities like BleachBit, I suppose.

What do you think?

PS : If that kind of list already exists, or there is an alternative way, or if I'm in the wrong section of the forum it's my bad, sorry.

Offline

#2 2020-05-09 09:35:41

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,058
Website

Re: Pacman user files

Those are config files not owned by pacman.  It should NOT touch them by design nor should bleachbit.  Also: https://wiki.archlinux.org/index.php/Ar … irectories

Last edited by graysky (2020-05-09 09:36:53)


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#3 2020-05-09 10:13:06

vogu66
Member
Registered: 2020-05-09
Posts: 3

Re: Pacman user files

Well, the question stands then : how would one go about removing automatically all files/folders in the home directory that are related to uninstalled packages, knowing that a number of these folders have a package-specific naming scheme?

Because it's not included in the package per say, but it is still invariably created when the program runs, and it accumulates.

Offline

#4 2020-05-09 12:17:26

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,191
Website

Re: Pacman user files

This is an ill-defined question.  Programs can create / name files however they like.  There is no general standard.  You can get an incomplete list on a case-by-case basis: w3m creates ~/.w3m, for example.  But you will miss many files with this approach, and there is no automated way to do this, you'd just need to base it on experience.

Worse yet, some programs will create temporary files, configs, or data with no static naming scheme.

On top of that there are files that you name (or at least give part of a name).  A game may prompt you for initials or a player ID and then save data in a file named after those initials, or those initials plus a date, or those initials hashed into an unrecongizable string of characters.

There are attempted standards such as the XDG which provide guidance on where programs should place each type of file, so then you'd know where to look to clean up after them - but not all programs follow these guidelines.  Other than XDG, the old defacto standard was "dot" files and directories in the home directory of any user that runs the program, you can see all these with "ls -ad ~/.*"  But still with that there is no direct correlation between package names, or even binary names, and files/directories.  They are generally recognizable (save for crap like .pki) but there is no simple algorithmic process to identify files or directories generated by a given package.

Lastly, you'd need to draw an arbitrary line between program-created data and user-created data.  From the computer's perspective, there's no difference.  If you install and run vim and deliberately create a text file called ~/my_important_notes, the vim binary creates that file, plus the .vim directory, and several other files, including .swp files with "my_important_notes" in the name.  If every file created by vim is removed, you'd lose your important data.  Where is the line between program created configs and data, user editted configs, user-named save-game states, and user's important notes?  There aren't any such lines.

So in short, there is no algorithmic / programmatic way to differentiate the files you like and the ones you don't.

Last edited by Trilby (2020-05-09 12:18:41)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-05-09 18:34:08

vogu66
Member
Registered: 2020-05-09
Posts: 3

Re: Pacman user files

Well that makes me come back to the initial idea, if there was a list on the computer (or online I suppose) somewhere of what each program may have had added as config/program-specific files only -- both user edited and not, because if you want to remove a program definitively then you don't need your edited config file, otherwise there is no point removing the config -- it would be possible to remove a lot of the problem.

If I re-take vim as an example, the '.swp' files that are created with '~/my_important_notes' are useful only for vim and placed in a specific file, so if there was somewhere a list saying ' "~/.vim" can be removed if vim is removed, and it's the only folder to remove' you'd be able to rule out '.vim' as a user file.

Now I'm not saying (anymore) that it should be integrated into pacman, since I also get that we don't want pacman to touch user files; but I still think it would be interesting to have the list somewhere -- either online or on the computer -- so that it's easy to make the difference between what's owned by the user, what's program-specific files that should be there, and what's program-specific files that shouldn't be there anymore.

Offline

#6 2020-05-09 18:54:12

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,191
Website

Re: Pacman user files

vogu66 wrote:

I still think it would be interesting to have the list ... to make the difference between what's owned by the user, what's program-specific files that should be there, and what's program-specific files that shouldn't be there anymore.

I'm not sure you got the point of my post.  All the files in question are owned by the user.  If you can't define what difference you are referring to (in a concrete or non-subjective manner) than there's no way to generate such a list.

What do you see as defining characteristics of the files you'd call "owned by the user" versus "program-specific files"?

Certainly we can give examples that are clearly on one side or the other, but there's a lot of grey area for which I don't know of any defining features.

Should gtkrc files be removed when a tool like lxappearance is uninstalled?  Should it matter whether those files were ever editted with some other tool (e.g., a text editor)?  If so, where / how would the data about which program modified which file be stored?

Last edited by Trilby (2020-05-09 20:25:27)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2020-05-09 19:59:09

zenbum
Member
From: California
Registered: 2020-02-29
Posts: 7

Re: Pacman user files

IMHO it would add an unnecessary burden to package maintainers if they were required to list all the config/temporary files created by using the package.

But surely there are straightforward ways to determine what config files are created in your home directory when a program is first run. You could use inotify, auditd, firejail, docker, etc, etc. I leave the details as an exercise for the reader. tongue

Offline

#8 2020-05-09 20:16:22

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 29,046
Website

Re: Pacman user files

It's your $HOME, so it is up to you to manage it.

One approach would be to put your $HOME under version control, then check the status after installing and running an application, and marking commits appropriately. You could then track which applications are responsible for which files in your VCS log.

Ultimately, as Trilby noted, this is something of a fool's errand, as there is no consistency in the Linux ecosystem. Some projects use the XDG spec, others just plaster their files randomly around your system. The best you can do is choose to use applications that are thoughtfully written, and respect standards.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#9 2020-05-09 20:28:03

a821
Member
From: My Location
Registered: 2012-10-31
Posts: 178

Re: Pacman user files

vogu66 wrote:

if there was a list on the computer (or online I suppose) somewhere of what each program may have had added as config/program-specific files only...

something like this?
https://wiki.archlinux.org/index.php/XDG_Base_Directory

Offline

#10 2020-05-09 20:29:55

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,191
Website

Re: Pacman user files

More damning counter-examples: you install vim and configure it the way you like.  Then you decide to switch to gvim which would have honored all of your settings, except, oh no pacman deleted your vim configs when you uninstalled vim!

Or perhaps you transition gradually from vim to neovim.  You have everything nicely configured in vim, and following reasonable advice, your neovim configs primarily just source your vim configs.  But then you realize you only ever use neovim, so you uninstall vim, and pacman takes all the configs - and you lose everything you were using in neovim.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#11 2020-05-09 20:59:53

zenbum
Member
From: California
Registered: 2020-02-29
Posts: 7

Re: Pacman user files

It would be trivial to write a wrapper script that extends the following:

$ (ls -d ~/.* && find ~/.config) | sort >~/foo.before
$ touch ~/.stupid_config
$ (ls -d ~/.* && find ~/.config) | sort >~/foo.after
$ diff ~/foo.before ~/foo.after
1052a1053
> /home/greg/.stupid_config

Just don't forget to use it the first time you run a program.

Offline

#12 2020-05-09 21:13:54

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,191
Website

Re: Pacman user files

It'd be even easier to just look at the output of `ls` and say "I don't want that there".


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#13 2020-05-10 08:11:50

davc0n
Member
Registered: 2020-02-01
Posts: 35

Re: Pacman user files

Trilby wrote:

It'd be even easier to just look at the output of `ls` and say "I don't want that there".

That's my approach since any attempt to automate this it's not 100% reliable, different cases have been mentioned.

Just remember to take a look and clean up your $HOME each time you remove a package. To get rid of the user config usually just a folder and sometimes an additional file has to be deleted.

Last edited by davc0n (2020-05-10 08:12:09)

Offline

Board footer

Powered by FluxBB