On Mon, 8 May 2023 at 03:57, Simon Richter <s...@debian.org> wrote: > > Hi, > > On 5/7/23 18:14, Ansgar wrote: > > > Is there any specific reason why specifically diversions are a problem > > where "it might work" is not sufficient? That is, why should we divert > > from the usual standard for dealing with packages outside the Debian > > ecosystem here? > > Locally created diversions are a supported feature, and the only way for > admins to replace single files in a way that is safe for installing updates. > > Even within Debian, it is not sufficient to just coordinate uploads of > packages that divert each others' files, because the new diversion needs > to be in place before a newly-canonicalized package is unpacked, a > Breaks relationship does not enforce that ordering, and while a > Conflicts without a Replaces does, this adds a lot of constraints to the > solver.
Sure, they are supported in the sense that they can be enabled, and then you get to keep the pieces. We ship thousands of maintainer scripts, and I have never seen one that takes into account completely arbitrary and random possible local diversion, apart from dash for /bin/sh (and we are about to nuke most of it!), when moving/adjusting/fixing and whatnot. Do you have any such counter-example in mind? Kind regards, Luca Boccassi
