Re: Second take at DEP17 - consensus call on /usr-merge matters
Helmut Grohne <helmut@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: