(context) In the "invisible application after upgrade" thread, Ed did not know how I did my upgrade to f33. I responded that I mostly followed the Fedora upgrade instructions from here: "https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/", and listed the sequence of commands that I did. That included the steps symlinks -r /usr | grep dangling symlinks -r -d /usr from the "Clean-Up Old Symlinks" section. Andras responded that
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
If Andras is correct, then the upgrade instructions need to be changed. Based on past experience, when a bug is submitted against Fedora documentation, the Fedora documentation team will want suggestions on how the document should be worded.
(question 1) What should the instructions say? Is there a better yet easy and safe way to find and clean out dangling symlinks? Maybe more detail should accompany "After you verify the list of broken symlinks"?
(question 2) In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program? What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
On Mon, 12 Apr 2021 at 14:13, home user mattisonw@comcast.net wrote:
(context) [...]
(question 2)
In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program? What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
The appropriate person to deal with dangling symlinks in a package is the maintainer. It doesn't make sense to include them in post-upgrade cleanup as that is just hiding buglets. There are several bugzilla reports many with duplicates.
https://bugzilla.redhat.com/show_bug.cgi?id=1185918 was "won't fix" because it was considered a question of packaging standards.
I gather that one proposal is to have rpmbuild refuse to package dangling links, but fixing all the broken packages will take work and the benefits are not large enough to justify the effort.
2021-04-12 19:12 UTC+02:00, home user mattisonw@comcast.net:
(context) In the "invisible application after upgrade" thread, Ed did not know how I did my upgrade to f33. I responded that I mostly followed the Fedora upgrade instructions from here: "https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/", and listed the sequence of commands that I did. That included the steps symlinks -r /usr | grep dangling symlinks -r -d /usr from the "Clean-Up Old Symlinks" section. Andras responded that
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
If Andras is correct, then the upgrade instructions need to be changed. Based on past experience, when a bug is submitted against Fedora documentation, the Fedora documentation team will want suggestions on how the document should be worded.
(question 1) What should the instructions say? Is there a better yet easy and safe way to find and clean out dangling symlinks? Maybe more detail should accompany "After you verify the list of broken symlinks"?
I don't know, but maybe a script that checks if the link belongs to a package, and only removes it if it doesn't. But I'm not sure it's worth the hassle. (Especially that that output of symlinks is not very useful in a script. As far as I can see, one would have to extract the filename from it using a(n adimittedly, probably quite simple) regexp.)
(question 2) In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program?
I'm not an expert but I'm pretty sure it's not.
What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
Probably no and yes. But it's not just hunspell. Far from it!
Andras
On Mon, 2021-04-12 at 11:12 -0600, home user wrote:
Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program?
A dangling pointer always points at something and is a clear and present danger if it's ever dereferenced. A dangling symlink doesn't point at anything.
What good, valid purpose is there for a package to have a dangling symlink?
I could imagine it being used as a kind of placeholder, but I wouldn't call it elegant.
poc
On Tue, Apr 13, 2021 at 10:17:56AM +0100, Patrick O'Callaghan wrote:
What good, valid purpose is there for a package to have a dangling symlink?
I could imagine it being used as a kind of placeholder, but I wouldn't call it elegant.
Firefox, for example, uses a dangling symlink to represent a lock file in your firefox profile directory. A bunch of different applications do the same thing, so it's not incredibly unusual to see them in your homedir.
On Tue, 2021-04-13 at 08:14 -0400, Jonathan Billings wrote:
On Tue, Apr 13, 2021 at 10:17:56AM +0100, Patrick O'Callaghan wrote:
What good, valid purpose is there for a package to have a dangling symlink?
I could imagine it being used as a kind of placeholder, but I wouldn't call it elegant.
Firefox, for example, uses a dangling symlink to represent a lock file in your firefox profile directory. A bunch of different applications do the same thing, so it's not incredibly unusual to see them in your homedir.
OK, I guess the point is to not use up an inode.
poc
On 4/12/21 1:15 PM, George N. White III wrote:
On Mon, 12 Apr 2021 at 14:13, home user <mattisonw@comcast.net mailto:mattisonw@comcast.net> wrote: [... snip ...] (question 2) In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program? What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
The appropriate person to deal with dangling symlinks in a package is the maintainer. It doesn't make sense to include them in post-upgrade cleanup as that is just hiding buglets. [... snip ...]
I agree.
On 4/12/21 1:47 PM, Andras Simon wrote:
2021-04-12 19:12 UTC+02:00, home user mattisonw@comcast.net: [... snip ...]
What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
Probably no and yes. But it's not just hunspell. Far from it!
I was assuming that hunspell was just one example.
On 4/13/21 3:17 AM, Patrick O'Callaghan wrote:
On Mon, 2021-04-12 at 11:12 -0600, home user wrote:
Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program?
A dangling pointer always points at something and is a clear and present danger if it's ever dereferenced. A dangling symlink doesn't point at anything.
ok, that makes sense.
What good, valid purpose is there for a package to have a dangling symlink?
I could imagine it being used as a kind of placeholder, but I wouldn't call it elegant.
agreed.
On 4/12/21 11:12 AM, home user wrote:
(context) In the "invisible application after upgrade" thread, Ed did not know how I did my upgrade to f33. I responded that I mostly followed the Fedora upgrade instructions from here: "https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/", and listed the sequence of commands that I did. That included the steps symlinks -r /usr | grep dangling symlinks -r -d /usr from the "Clean-Up Old Symlinks" section. Andras responded that
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
If Andras is correct, then the upgrade instructions need to be changed. Based on past experience, when a bug is submitted against Fedora documentation, the Fedora documentation team will want suggestions on how the document should be worded.
(question 1) What should the instructions say? Is there a better yet easy and safe way to find and clean out dangling symlinks? Maybe more detail should accompany "After you verify the list of broken symlinks"?
(question 2) In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program? What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
Having read 5 responses, my impression thus far is that the best change to request in the upgrade instructions is to either remove the "Clean-Up Old Symlinks" section altogether or make no changes at all.
On 4/12/21 11:12 AM, home user wrote:
(context) In the "invisible application after upgrade" thread, Ed did not know how I did my upgrade to f33. I responded that I mostly followed the Fedora upgrade instructions from here: "https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/", and listed the sequence of commands that I did. That included the steps symlinks -r /usr | grep dangling symlinks -r -d /usr from the "Clean-Up Old Symlinks" section. Andras responded that
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
If Andras is correct, then the upgrade instructions need to be changed. Based on past experience, when a bug is submitted against Fedora documentation, the Fedora documentation team will want suggestions on how the document should be worded.
(question 1) What should the instructions say? Is there a better yet easy and safe way to find and clean out dangling symlinks? Maybe more detail should accompany "After you verify the list of broken symlinks"?
(question 2) In a later post, Andras provided and example of a dangling symlink (in the "hunspell" package) that should not be deleted. When I was a C/C++ programmer (a long long time ago, in a galaxy far far away), dangling pointers (and memory leaks) were naughty; they can cause serious problems. Isn't a dangling symlink a file system parallel to a dangling pointer in a C/C++ program? What good, valid purpose is there for a package to have a dangling symlink? Or maybe "hunspell" needs a little clean-up?
I have submitted a bug. Here is the link: "https://bugzilla.redhat.com/show_bug.cgi?id=1952656".
-
Andras Simon -
George N. White III -
home user -
Jonathan Billings -
Patrick O'Callaghan