Le mar. 25 avr. 2023 à 19:08, Helmut Grohne <hel...@subdivi.de> a écrit : > > Hi Luca, > > On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote: > > On Sat, 22 Apr 2023 at 11:50, Helmut Grohne <hel...@subdivi.de> wrote: > > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > > > > After Bookworm ships I plan to propose a policy change to the CTTE and > > > > policy maintainers to forbid shipping files in the legacy directories > > > > altogether, followed by a debhelper change to adjust any stragglers > > > > automatically at build time and a mass rebuild, plus MBF for the small > > > > % that does not use dh and a piuparts test to stop migration for > > > > anything that is uploaded and doesn't comply. That should bring the > > > > matter to an end, without needing to modify dpkg. > > > > > > I agree with the goal of removing aliases by moving files to their > > > canonical locations. However, I do not quite see us getting there in the > > > way you see it, but maybe I am missing something. As long as dpkg does > > > not understand the effects of aliasing, we cannot safely move those > > > files and thus the file move moratorium will have to be kept in place. > > > And while moving the files would bring the matter to an end, we cannot > > > do so without either modifying dpkg or rolling back the transition and > > > starting over. I hope that we all agree that rolling back would be too > > > insane to even consider, but I fail to see how you safely move files > > > without dpkg being changed. Can you elaborate on that aspect? > > > > Moving files within _the same_ package is actually fine as far as I > > know. It's moving between location _and_ packages within the same > > upgrade that is problematic. The piuparts test I added is overzealous, > > but it doesn't need to be. > > You got me interested to dig deeper. I looked into that piuparts > check[1]. From what I understand, it does something differently from > what you suggest here. It detects files moved between / and /usr (which > is what is going to happen according to your plan) and it does not > detect files being moved between packages (which would actually be > problematic here). It also does not produce an error (merely a warning), > so it doesn't halt testing migration and in particular, it doesn't > detect the problematic situation at all. That's kinda disappointing. > > You also side stepped the question of how to handle the situation where > we've moved files from / to /usr and then need to move files between > packages in a safe way, though your other response to Simon McVittie > suggests you have an idea there. > > On Sat, 22 Apr 2023 13:03:01 +0100, Luca Boccassi wrote: > > We already have piuparts tests detecting files moving, it should be > > easy enough to extend that to check that the appropriate > > Breaks/Replaces have been added. Correct me if I'm wrong, but I > > believe it's already against policy to do this without > > Breaks/Replaces, so it's not a use case that we need to support, no? > > If someone does that by mistake, the package will not migrate to > > testing. > > Yeah, we agree that you need Breaks+Replaces. The issue here is that due > to dpkg not knowing about the aliasing, Breaks+Replaces is insufficient. > Due to the insufficiency the CTTE enacted the moratorium. > > My impression is that you believe that with bookworm, the moratorium is > being lifted and thus we can start moving files. Unfortunately, the > underlying problem does not go away just because we've released > bookworm. It's a problem that is unique to merged installations and > those are not going to go away in bookworm. > > So yeah, we all want these files moved to their canonical locations and > I kinda like the simplicity of your approach, but thus far my > understanding is that it is plain broken and doesn't work. Well, yeah it > does work in the sense that we break user installations during upgrade > and notice so late in the freeze without any good options to fix. > > On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote: > > > I'd also be interested on how you plan to move important files in > > > essential packages. This is an aspect raised by Simon Richter and where > > > I do not see an obvious answer yet. > > > > Do you have a pointer? Not sure I follow what "important" files means > > here, doesn't ring a bell. > > In <669234b3-555b-4e2a-ccc7-dd5510b6e...@debian.org>, Simon Richter > said: > > Dpkg already has defined behaviour for directory vs symlink: the directory > > wins. In principle a future version of dpkg could change that, but > > /lib/ld-linux.so.2 is just too special, we'd never want to have a package > > that > > actually moves it. > > This and /bin/sh is the kind of files I'd consider important. And then > upon thinking further it became more and more difficult for me to make > sense of the objection. On a merged system, we can just move that file > to its canonical location without having any trouble even with an > unmodified dpkg. So from my pov, the question about important files can > be disregarded. I hope Simon Richter agrees. > > Let us circle back to your "broken" approach. It sure is simple (just > move all the files and be done) and if we could just skip over the > upgrade issues and have all the files moved without having to modify > dpkg, that would actually be a better result than DEP 17. Just how do we > avoid the issue of file loss arising from the aliasing in your scenario? > > There kinda is an obvious solution here. We just need to tell dpkg that > it needs to remove the package containing the file that is being moved > before unpacking the replacing package. This semantic actually exists > and we call it "Conflicts". So instead of using Breaks+Replaces, the > solution is to use Conflicts! Problem solved, right? > > Yeah, I think this solves a number of cases, but there are two areas > where it does not: > * We generally prefer Breaks over Conflicts for a reason. It gives the > dependency resolver more freedom and in taking this freedom away, it > may fail to find solutions to complex upgrades. (Which is why Breaks > got introduced in the first place.) > * We cannot use Conflicts inside the transitively essential set. > > So if we move all those files, in 90% (number made up) of the cases it > will go well (since we don't move between packages) and in 90% (number > made up) of the remaining 10%, we can use Conflicts, but what do we do > about that remaining 1%? > > If we look deeper into the dpkg toolbox, we pause at diversions. What if > the new package were to add a (--no-rename) diversion for files that are > at risk of being accidentally deleted in newpkg.preinst and then remove > that diversion in newpkg.postinst? Any such diversion will cause package > removal of the oldpkg to skip removal of the diverted file (and instead > deleted the non-existent path that we diverted to). Thus we retain the > files we were interested in. > > This way, we can just move the files as you suggested. > * For 90% of the packages, this will just work. > * For 9% of the packages, we'll need to turn Breaks+Replaces into > Conflicts. > * And for 1% of the packages, we'll need to add complex diversions to > maintainer scripts.
Do we have a tool to classify the packages ? Bastien
