* Ansgar <ans...@43-1.org> [210822 05:08]: > Hi Guillem, > > On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > > There was talk about the huge amount of symlinks required in a > > symlink farm setting, but that might have been true for a scenario > > where those symlinks would have been handled automatically and > > transparently. > > To get a filesystem layout equivalent to merged-/usr via symlinks > farming *every* package shipping files in at least /usr/bin, /usr/sbin > and possibly some of /usr/lib would need to include symlinks in /bin, > /sbin, /lib. This would affect far more packages than updating the > packages currently shipping files in /bin, /sbin and /lib* to ship > these under /usr instead.
It is true that for a symlink-farm-usr-merge system to be strictly equivalent to a symlink-dir-usr-merge system, many packages that never had /bin/foo but had /usr/bin/foo would have to add a symlink /bin/foo, however this is clearly unnecessary. The problem that the symlink farm is solving is that scripts (distributed or user-written) that depend on /bin/foo need to continue to work on a partially merged system. A previous message (already deleted, so I'm not sure from whom) clearly identified 240 packages (number pulled from memory, so might be off) that would have to put symlinks in /bin and /sbin for the symlink-farm-usr-merge strategy to work. The amount of work is orders of magnitude less than you are representing. There is no need for the symlink-farm to exactly match the symlink-dir solution. The union of systems during the symlink-farm merge and systems after the merge is complete can _only_ count on /bin/foo existing if it existed before the merge was started. There is no need for anything else (wrt /bin/foo existing). ...Marvin