Re: merged-/usr-via-symlinks vs a-different-layout
On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
> Guillem Jover writes:
> > You are still conflating the concept with the deployment. The
> > underlaying properties of merging /usr is that the contents for
> > directories that are present in both / and /usr get merged into
> > /usr.
>
> No, I'm saying that you are proposing yet another different file system
> layout. Which is quite simple to see: the file system would differ.
>
> You just claim it follows similar "ideas" in some way.
Again, no, the important part is that the contents get *moved*
properly and *automatically* within the .deb packags, the only
difference is that for a transition period we'd have most of those
files that currently live in / as symlinks to /usr. Most of those
(not all, obviously) would eventually disappear.
The main difference between the two deployments is how the move is
done, and how and which compat symlinks are setup.
> I can come up with other variations that move files to /usr too: have
> /bin a symlink to /usr/root/bin (some for other directories). That
> would also be a different file system layout which shouldn't be called
> "merged-/usr" either.
Err, well sure, because that'd not be merged-/usr, obviously. The
contents would not end up being moved/merged into their counterparts
on /usr. This just looks like a straw man…
> (That would have no filesystem aliasing between /bin and /usr/bin;
> policy has special rules to allow replacing top-level directories with
> symlinks; but besides that it is different for no good reason so I don't
> think it would be a good idea.)
The rationale for the policy and dpkg support for moving directories
into other places and then symlinking them, was for space constrained
purposes (say move /lib to /srv/lib, or even /usr to /srv/usr). These
never create filesystem aliasing problems, because no one had before
tried to point those dpkg owned directories contents into another dpkg
owned directory and then symlinking the directories. This should be
obvious from the fact that before the merged-/usr-via-symlinks hack
got forced in, many packages needed to be changed (not fixed really)
to cope with the newly introduced aliasing problems.
> > See for example OpenSUSE which did this transition correctly:
> >
> > <https://en.opensuse.org/openSUSE:Usr_merge>
>
> "The special comments #UsrMerge, #EndUsrMerge will help us to clean up
> the spec files once everything has been moved and we can create a
> general link from /bin to /usr/bin for example. "
>
> So they want a /bin -> /usr/bin symlink (and the same for the other
> directories) just as in the proposal you call broken...
>
> Maybe you have misunderstood what SuSE plans to do?
Well, they did a proper transition, and AFAIUI they have not yet
botched the final part.
> Having dpkg track a symlink /bin/${something} and a file
> /usr/bin/${something} will break should /bin be turned into a symlink
> happen.
Only if that symlink is aliasing an existing dpkg owned directory. Which
well, clearly should not be done. If the admin moves the directory
somwehere else (not owned by dpkg), that does *not* create aliasing
problems.
> So there is no nice way to finish the transition. I'm not sure
> how that would work on RPM; maybe SuSE got stuck with that? That would
> be another good reason to not follow that way...
If by "finishing the transition" you mean ending up deploying
merged-usr-via-symlinks, well then I guess you missed the entire point
of my mail. It would be pointless to do it by properly moving the
files in the .debs, creating compat symlinks to then botch it at the
end again with the directory symlinks, we might as well botch it from
the beginning. :/
The transition would be finished simply when no (non-required) compat
symlinks are present under the / directories. So we'd remain with just
a few things like /bin/sh and similar required for historical reasons.
> I wouldn't be surprised if that took about as long as the /usr/doc ->
> /usr/share/doc transition. (If the change process for most simple
> changes like file locations takes 10+ years then I say the process is
> broken...)
As mentioned in my earlier mail, the main difference is that in this
case the move can be fully automated, w/o any initial maintainer
intervention whatsoever. The only thing that requires maintainer
internvation is the analysis and cleanup of the compat symlinks in
the .deb, but that's really not urgent at all in any case.
Regards,
Guillem
Reply to: