Re: Another usrmerge complication
Hi Simon and Simon,
On Sun, Mar 17, 2024 at 12:08:21PM +0000, Simon McVittie wrote:
> 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.)
That is also my interpretation.
> So I think the precise way in which the system goes wrong in this
> situation is unimportant, because the situation already shouldn't
> exist?
Yes, and I can also tell you why such a situation does not 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.
https://salsa.debian.org/helmutg/dumat detects and files these issues.
Since we typically handle file conflicts with Breaks+Replaces and
Replaces may be rendered ineffective due to aliasing, it is important
that we correctly declare all Replaces relations (that involve paths
subject to aliasing). For this very reason, dumat causes reports (rc
bugs) for all such conflicts disregarding aliasing. Say package foo
contains /lib/foo and package foo2 contains /usr/lib/foo without a
package relation nor diversion, an rc bug would be created (and of
course this also holds for bin and sbin).
I think we're good in this regard.
> 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.
At that point we get an unpack error from dpkg rather than silent file
overwrite, yes, but that still warrants a QA tool. Andreas Beckmann
seems to file such issues fairly reliably.
Helmut
Reply to: