Helmut Grohne <hel...@subdivi.de> writes: > On Wed, Jun 28, 2023 at 02:55:28PM -0600, Sam Hartman wrote:
>> I think you might get a more clear consensus if you phrase that in >> terms of whether people are willing to wait for major changes in dpkg. >> If the dpkg maintainer were to merge aliasing support, I haven't seen >> anyone objecting strong enough to try and override that maintainer >> action for example. > I think this is a misrepresentation. There is no readily mergable patch > for aliasing support. The most complete one is the tree from Simon > Richter and he considers that work incomplete still. At this time, it's > no a question of merging or not really. > From my point of view, the question really is whether we want to > permanently extend dpkg's features in a way that we only really see > useful for one transition while still having to maintain it for > backwards compatibility. I think I fall into the category that Sam is thinking of. I don't agree that aliasing support in dpkg is useful only for this transition. I think there are other cases where two directories could end up being aliases for the same directory. However, I have been convinced that changing dpkg to properly support this will take longer than I'm willing to wait given the problems that the /usr-merge transition is causing right now, and therefore I agree with a consensus that we shouldn't wait for dpkg aliasing support (even though I disagree, I think, about the long-term usefulness of that support). I am very disappointed that we have not successfully added aliasing support to dpkg, which to me is the obviously correct way of addressing this problem architecturally. To me, this says sad and depressing things about the state of the project that we have not been able to do this. What Sam is trying to say, I think, is that a different phrasing offers a way to avoid that discussion and agree to disagree on the best architecture in the abstract by pointing out an additional constraint: how long we're willing to wait and how uncomfortable we're willing to make things for ourselves to try to force the dpkg changes to appear. > Can we maybe turn the question upside down and phrase it in terms of how > to place the aliasing symlinks? > Option #3d: > A binary package (such as base-files) shall contain the aliasing > symlinks in its data.tar. > Option #3e: > No package shall contain the aliasing symbolic links in a data.tar > and dpkg shall not track them in its filesystem database. I really would like us to work towards #3d in the longer term. I'm convinced by josch's argument here. But I would be willing to go with a short-term consensus around doing #3e for now, as long as we're not foreclosing on doing this properly via #3d in the future. (I think there are some reasons to believe that once most of the file moves in data.tar.gz have happened, the ones that are currently blocked by not having a solution for this transition, it will be easier to get to #3d from #3e than it is right now.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>