12:12 p.m.
(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?
2:15 p.m.
New subject: dangling symlinks and upgrades (was "invisible application after upgrade").
On Mon, 12 Apr 2021 at 14:13, home user <mattisonw(a)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.
--
George N. White III
12:05 p.m.
On 4/12/21 1:15 PM, George N. White III wrote:
On Mon, 12 Apr 2021 at 14:13, home user <mattisonw(a)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.
2:47 p.m.
New subject: dangling symlinks and upgrades (was "invisible application after upgrade").
2021-04-12 19:12 UTC+02:00, home user <mattisonw(a)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
12:08 p.m.
On 4/12/21 1:47 PM, Andras Simon wrote:
2021-04-12 19:12 UTC+02:00, home user <mattisonw(a)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.
4:17 a.m.
New subject: dangling symlinks and upgrades (was "invisible application
after upgrade").
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
7:14 a.m.
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.
--
Jonathan Billings <billings(a)negate.org>
10:28 a.m.
New subject: dangling symlinks and upgrades (was "invisible application
after upgrade").
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
12:09 p.m.
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.
12:13 p.m.
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.
1:53 p.m.
New subject: dangling symlinks and upgrades (was "invisible application after
upgrade"). [CLOSED]
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".
1098
days inactive
1108
days old
10 comments
5 participants
participants (5)
-
Andras Simon -
George N. White III -
home user -
Jonathan Billings -
Patrick O'Callaghan