On Mon, Feb 26, 2024 at 11:38:58AM +0100, Michael Biebl wrote: > > > Am 25.02.24 um 19:30 schrieb Andrea Bolognani: > > Right there with you. I just don't want to rush things, especially > > since AFAIK some really problematic scenarios can be triggered when > > paths are canonicalized at the same time as they are moved across > > binary packages. > > This is correct. Moving files between packages and from / to /usr at the > same time corresponds to the file loss scenario described at > https://subdivi.de/~helmut/dep17.html as P1. > See also > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=dep17p1
Note that "at the same time" can mean two things in this context: 1) when upgrading from bookworm to trixie; 2) when upgrading testing/unstable. I'm sure that 1) can be handled correctly, but the prospect of causing file loss for 2) by accident is not particularly appealing and I'd like to avoid it if at all possible. > > Going forward, I will focus all the time I can spend on Debian on > > reorganizing the libvirt package to enable modular daemons. I hope to > > have at least a rough implementation ready within a few weeks. > > I don't think postponing the usr-merge changes helps mitigating any issues > since those need to happen for trixie in one way or another. > > My recommendation is to upload the current patch in this bug report soon, > and do the package re-organisation later via an upload to experimental. > dumat will then pick up any potential issues. > See the recommendations in https://wiki.debian.org/UsrMerge As I've explained we want to preserve backportability as much as possible, which pretty much rules out the current patch. At the very least we'd have to use dh_movetousr instead. What I still fail to understand, and please bear with me because the issue is most likely on my side, is how the fallout from a "bad" file move would be dealt with. Suppose that I made the usr-merge upload today, and the package restructure upload in a month. At that point, dumat would detect that file loss could occur, report it and... What then? Have reliable mitigations been developed for all possible file loss scenarios? Is it guaranteed that such mitigations, when applied, will protect from file loss not just the people running stable, but also those running testing and unstable? My instincts tell me that it would be much easier to reason about this if the two transitions happened at the same time rather than potentially months apart. This is my main concern with applying the usr-merge changes when we still don't have a clear picture of what the final state of the package will look like. -- Andrea Bolognani <e...@kiyuko.org> Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature