1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Another usrmerge complication

    From Simon Richter@21:1/5 to All on Sun Mar 17 03:30:01 2024
    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)
  • From Simon McVittie@21:1/5 to Simon Richter on Sun Mar 17 13:10:02 2024
    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)
  • From Helmut Grohne@21:1/5 to Simon McVittie on Sun Mar 17 21:10:01 2024
    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)