XPost: linux.debian.maint.dpkg

Hi,

because life isn't hard enough as it is: 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, then, if both are installed in the same
dpkg invocation, the contents of the first package end up being
installed, while in two separate invocations, the second package's
contents win.

So for any undetected file conflict, which file now exists now depends
on whether apt decided to install both packages during the same
installation round or not.

Writing more test cases,

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.dpkg

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.dpkg

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)