Sam Hartman: >>>>>> "Niels" == Niels Thykier <ni...@thykier.net> writes: > > Niels> As I understand it, the issue does not depend on whether > Niels> "usrmerge" is run before or after installing the "/lib" > Niels> version of "foo". On that assumption, running "usrmerge" as > Niels> a part of the upgrade and "cleaning up" in bookworm+1 is > Niels> liable to exactly the same risk as before. > > I don't think so. > My assumption is that we will eventually produce a dpkg that handles > this situation better.
I can appreciate the allure of assuming that "a fixed dpkg" appears and solves the entire problem. It would certainly make all the problem go away *if* it appears. I am not ready to believe in that dpkg as a solution to the bookworm release because the dpkg development flow has never been "fast" due to a strong focus on "a generic solution that gets it right in every case" - and I expect it to be even slower than usually given how demotivated Guillem feels and the complexity involved in such a change to dpkg. And until the "fixed" dpkg materializes, every package shipping something has to keep files in /lib - even if that is a decade after the bookworm release - or risk breaking if they later need to split the package in the same release cycle. To me, that sounds like we will drag the transition on "until the fixed dpkg comes along" no matter how long it takes. Finishing the transition is a key element for me in the transition. > [...] > So my hope is that debhelper and maintainers refrain from moving files > from / to /usr prior to being able to depend on an as yet unwritten > dpkg. > For me, this reads as "until = eventually", which I stated I would find unconvincing. For the record, I did not immediately expect a better answer which is also why I am waiting with moving forward in case a better answer materializes "soon". > I think that if debhelper moves systemd units and later a maintainer > moves units between packages, we can run into trouble with today's > dpkg. So we could potentially run into trouble as soon as someone > installs such a package from testing onto a bullseye system. > > If debhelper were to hold off until after a fixed dpkg exists and we can > guarantee it is available, > I think that we avoid the risk of files disappearing. > So, based on my understanding, I think the risk is worse today than it > would be if we rolled back the debhelper change. > > > [...] > > > It's possible I'm missing something . > If so, I'd appreciate help understanding what it is. > On the assumption that a "fixed" dpkg will appear in bookworm, I would agree with you. However, I do not believe in that assumption/timeline - to explain why I believe we fundamentally disagree on the priority/solution. > This strongly depends on: > >> * Who volunteered to be the >> "we" that provide this plan? >> * When is "until" we have a >> defined plan? > > So, I think that the discussions here have been converging on things > that would work. > I'm happy to volunteer to assist in trying to find what consensus there > is if that helps. > I appreciate you volunteering to a part of it. My interest in a detailed transition plan with a fixed end date where we are *done* with the "clean up" no later than bookworm+1. I do not see that directly in these discussions - but certainly, a consensus is probably the first step there. Maybe the consensus will motivate someone to volunteer to create the plan. (Side-note my desired timeline implies that a "fixed" dpkg lands in bookworm.) > [...] > > So I don't actually know how to get to something actionable. I do > believe the chance of breakage if we move around paths inside packages > is high enough that we should block path canonicalization on a dpkg that > can handle that, even if that takes a long time. > I would strongly prefer a timely actionable transition plan that does not involve assuming a "fixed" dpkg will show up and magically fix everything when the volunteer working dpkg is strongly demotivated by this transition. In the absence of such a transition plan ... If the project consensus of this discussion is aligned with the belief that we should block decentralized volunteer work on the transition, I will respect the decision. ~Niels
