Hi Christoph, On Wed, Jun 19, 2024 at 05:26:14PM +0200, Christoph Biedl wrote: > an observation: When comparing the result of a manually adjusted > softflowd (upload pending) and the result of dh-sequence-movetousr, I > noticed a difference in the init script (using a private > re-implementation of debdiff as the original one does not show this for > whatever reason):
It is correct that dh-sequence-movetousr does not look into files and merely shuffles them around. > So, the dh-sequence-movetousr helper did not cover this but, quite > frankly, I didn't expect it to do so. Good. > However, in my opinion it is prudent to completely stop referring to > the legacy places. Compatability symlinks are in place, and will be for > a long time. But when I touch the packaging, I'd prefer create a robust > result, not something that just works. The goal you are picturing is not attainable. There is no reasonable way we are going to stop using "#/bin/sh" or "/lib64/ld-linux-x86-64.so.2". Given that these will never go away, you may fully rely on these symlinks. > This might or might not be in the scope of DEP-14, so feel free to > take this as a bug report, as some information, or just anecdotical. I think you mean DEP17. > Personally however, I'd implement at least some rudimentary checks > for the situation of referring to files in the legacy places, and file > reports with a rather low priority - until somebody decides to remove > the compat symlinks in a future Debian release. I believe such effort is not a good use of our time. The reason for moving files around is to avoid a bug class. The reason for referring to files via their physical paths is much less well-motivated. Hence, I recommend not spending time on it, but then I won't stop you either. On a technical level, I see little advantages or disadvantages about using either path. Helmut
