On 2023-02-28 10:26:07 -0700, Sam Hartman wrote: > >>>>> "Sebastian" == Sebastian Ramacher <sramac...@debian.org> writes: > > Sebastian> Can you expand your concern? I expect that this issue > Sebastian> goes away as soon as we can assume that all systems are > Sebastian> /usr-merged. At that point I expect that we are able to > Sebastian> drop the workaround from debhelper and packages can move > Sebastian> the files to the expected location without issues. > > Quoting the TC advice: > > > > > - On merged-/usr systems, there is a possible failure mode involving > > files being moved between packages (with Replaces) during the same > > release cycle that their logical location is changed from the root > > filesystem to the corresponding aliased directory in /usr, which > > can > > result in the affected file disappearing. This can be avoided by > > not > > changing the file's logical location until the beginning of the > > Debian > > 13 development cycle, after the transition to merged-/usr is > > complete. > > > I think it is only true that files can move in the Debian 13 cycle if > the dpkg issues are fixed. > If dpkg is not fixed, then the issue with replaces interacting badly > with file moves will still exist. > > Moreover, I suspect in a number of the cases related to this current > bug, replaces will be likely. I suspect that in some of the cases where > units have been introduced that are disabled currently, but will be > enabled by the dh_installsystemd change, we will discover we'd like > those units disabled in some configurations. A logical way to handle > that may be to split out the units into separate packages. > That makes the replaces interacts with file moves class of bugs more > likely in this situation than average.
The TC advice refers to files moving between packages which wouldn't be the case here (at least not in general). Cheers -- Sebastian Ramacher
