Re: Another usrmerge complication
On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote:
> When /bin is a symlink to usr/bin,
> and I install two packages, where one installs /bin/foo and the other
> installs /usr/bin/foo
My reading of Policy is that this situation is already a Policy violation:
To support merged-/usr systems, packages must not install files in
both /path and /usr/path. For example, a package must not install
both /bin/example and /usr/bin/example. —§10.1
and in the case of /{usr/,}{s,}bin in particular (which is the most likely
place for this to happen), doubly so:
Two different packages must not install programs with different
functionality but with the same filenames —also §10.1
(I'm interpreting that as "install programs into the PATH" which I hope
is the intended reading.)
So I think the precise way in which the system goes wrong in this
situation is unimportant, because the situation already shouldn't
exist?
Until we reach the point where every package's data.tar contains only
non-aliased paths (files below /usr, /etc and /var, plus additional
top-level paths in base-files), it seems to me like the best way to
handle this would be a QA tool that detects any such situations that might
exist in the archive, and makes sure they have appropriate Conflicts to
stop the bad scenario from occuring in practice.
But, after we reach the point where every data.tar contains only
non-aliased paths, by definition this situation cannot arise, because
there will be no remaining packages with files /bin/foo, /sbin/foo
or /lib*/foo. It seems like we are quite close to that point (mainly
thanks to Helmut's efforts in that direction) after which this will be
a non-issue, so maybe providing such a QA tool would be a wasted effort.
smcv
Reply to: