Re: usrmerge -- plan B?
- Date: Sun, 23 Dec 2018 21:07:25 +0100
- From: Martin Steigerwald <martin@xxxxxxxxxxxx>
- Subject: Re: usrmerge -- plan B?
Guillem Jover - 23.12.18, 17:17:
> On Sun, 2018-12-23 at 16:45:28 +0100, Guillem Jover wrote:
> > On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote:
> > > […] They also imply to permanently suffer the aliasing problems.
> > To expand and clarify a bit on this. We have aliasing in general
> > with
> > symlinks and hardlinks, but those tend to not be as problematic when
> > aliasing the last component, as they end up referencing the same
> > object/inode. The problem really comes when the aliasing is
> > performed
> > as part of the pathname (in a "directory" component), because then
> > the aliasing references the dentry, which can very easily cause
> > "action at a distance" issues.
> Hrrmf, clearly not very clear. Let's try again:
> - Aliasing directory components can create multiple source pathnames
> (before any readlink) that refer to the exact same dentry. - Aliasing
> final components means that the source pathnames are always
> different, and as such they always point to different dentries, even
> if they might end up pointing to the same destination pathname once
I think I have seen this with either SLES or RHEL that they created
symlinks for every binary in /bin and /sbin, pointing to the binary in
/usr/bin and /usr/sbin. I did not understand why at the time I have seen