Hi!
I tried to find out which files on my upgraded fc40 installation are not installed via dnf/rpm. The list is surprisingly long. Main reasons are symlinks and directories not defined in the spec file. A quick check shows that this is also the case with a fresh installation.
I see three reason for having this clean: *) Knowing which files comes from installations outside dnf/rpm. Maybe this is security related? *) Making some kind of clever backup (list of RPMs and only additional/changed files) *) Removal or Upgrade of RPMs/distribution should not left files behind.
Should this be (slowly) cleaned up or do I see this too strict?
PS.: Two of my packages had this also. :)
Best regards Christoph
I tried to find out which files on my upgraded fc40 installation are not installed via dnf/rpm. The list is surprisingly long. Main reasons are symlinks and directories not defined in the spec file. A quick check shows that this is also the case with a fresh installation.
I see three reason for having this clean: *) Knowing which files comes from installations outside dnf/rpm. Maybe this is security related? *) Making some kind of clever backup (list of RPMs and only additional/changed files) *) Removal or Upgrade of RPMs/distribution should not left files behind.
Should this be (slowly) cleaned up or do I see this too strict?
I agree with all of your reasons. This clean up process has been going on since Fedora 1. For two early examples, see:
https://bugzilla.redhat.com/show_bug.cgi?id=117163 https://bugzilla.redhat.com/show_bug.cgi?id=164498
I don't recall an organized effort at this; perhaps someone else will.
On Wed, 1 May 2024 12:49:32 -0500, W. Michael Petullo wrote:
This clean up process has been going on since Fedora 1.
FWIW, my mass-filings of "unowned directory" bugzilla tickets has had poor responses by packagers eventually and therefore has been discontinued.
Instead, a section has been included in the packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories...
On Thu, May 2, 2024 at 1:21 AM Christoph Karl via devel < devel@lists.fedoraproject.org> wrote:
I tried to find out which files on my upgraded fc40 installation are not installed via dnf/rpm. The list is surprisingly long.
Perhaps you could upload the list to fedorapeople or somewhere? Maybe also the script you used?
Main reasons are symlinks and directories not defined in the spec file.
A quick check shows that this is also the case with a fresh installation.
Hi!
Am 01.05.24 um 19:58 schrieb Jens-Ulrik Petersen:
On Thu, May 2, 2024 at 1:21 AM Christoph Karl via devel < devel@lists.fedoraproject.org> wrote:
I tried to find out which files on my upgraded fc40 installation are not installed via dnf/rpm. The list is surprisingly long.
Perhaps you could upload the list to fedorapeople or somewhere? Maybe also the script you used?
find /usr/ -exec /usr/bin/bash -c 'rpm -qf -- "$1" >/dev/null 2>&1 || echo "$1"' find_sh {} ;
The list itself strongly depends how long your are already upgrading fedora and which packages you have installed.
Dne 01. 05. 24 v 7:20 odp. Christoph Karl via devel napsal(a):
*) Removal or Upgrade of RPMs/distribution should not left files behind.
Two cases where files are intentionaly left behind:
1) configuration files
This can be handled by:
rpmconf --all --conf
2) %ghost files - usually log files. You surely want to keep them and on disk. But not all spec files mark them as ghost - usually owns only the directory and not the files. And if they own the file itself, then rotated files are not owned for sure.
I have no solution for this.
find/usr-exec/usr/bin/bash-c'rpm -qf
Ouch you are looking for files in /usr only. So you do not consider the two cases above at all.
In my case it found BTW:
/usr/bin/anime-games-launcher
I am not sure how others appear there, but I know this one. It comes from
https://copr.fedorainfracloud.org/coprs/retrozinndev/anime-games-launcher
and the spec file has:
https://download.copr.fedorainfracloud.org/results/retrozinndev/anime-games-...
%post # create link of binary ln -sf %{install_dir}/%{name} %{_bindir}/%{name} # apply exec permision to binary chmod +x %{install_dir}/%{name}
Not sure if this can be handled on distribution level. For packages from 3rd party repos.