Hi Branden, On Thu, Jan 09, 2025 at 01:41:16PM -0600, G. Branden Robinson wrote: > > Fundamentally, I assumed that dpkg-divert --rename would only move a > > file if it was considered installed according to the dpkg database. > > What really happens is that --rename moves a file as long as it > > exists. > > Is that within dpkg's specification? If it is, in fact, a bug, should > we consider tackling it for the next development cycle?
Really? We are very deep in the land of implementation-defined behaviour. From a specification point of view, I'd call doing diversions on aliased files undefined behaviour. It really does not matter at all whether we call this a bug or anything. At the time our maintainer scripts run, we must expect them to run with bookworm's or trixie's dpkg and we cannot rely on any change in behaviour to be applied to the former one. The only thing that we care about is that as little as possible implementation-defined behaviour in this area changes between bookworm and trixie. Luckily, Guillem put his effort into other valuable areas of dpkg that are less of a concern for the /usr-move. Then when it comes to the next development cycle, the idea is that we have left aliasing behind. In the common case, if there is an untracked file in a location that is being diverted, the present --rename semantics arguably are useful as the untracked file will be renamed (on installation) and back (on removal). I asked Guillem off list to consider documenting this aspect. Helmut
