Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Russ,
On Thu, Jun 29, 2023 at 11:51:57AM -0700, Russ Allbery wrote:
> 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).
To me, this leaves more question marks than earlier. What applications
of aliasing do you envision that would benefit here? Anything concrete?
Why did you see waiting for a dpkg patch as a reasonable approach
earlier? I think we have roughly three categories of dpkg changes on the
table:
* Minimal hacks that would paper over some of the effects without
causing a generally applicable aliasing support
* A mechanism where dpkg is being told about aliasing symlinks
explicitly and thus would work with them
* An extension of the dpkg filesystem database wherein it would be able
to determine the filetype for every filesystem object. In particular,
this would allow it to tell directories from symlinks apart and
handle the overlap in a meaningful way.
Which of these do you consider "aliasing support"? I expect that you
would not consider the first category. The third category is quite
involved. Since it changes the internal layout of dpkg's database, a
prerequisite for doing this is removing direct accesses to the database
by other tools. Guillem has been doing that work and you can find more
information about it at
https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking. Note that this
work goes beyond what is needed for aliasing as it also considers
extending the metadata format in binary packages to be able to represent
e.g. extended attributes. Did you expect Guillem to implement this
faster? The second category seems fairly narrow and tailored to the
/usr-merge application. Do you consider it to support aliasing in the
generic way that you had in mind? Since Guillem is working on the third
category, whom did you imagine to be working on the second one?
> 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.
Please bear in mind that a general form of aliasing support entails all
sorts of crazy corner cases. In the earlier thread, Simon Richter
highlighted some of them. We'd need to come up with reasonable semantics
for the case where a package wants to install a symbolic link to a
location that is already occupied with a directory for instance. We also
need to figure out what happens when we remove that package. What
happens when the symbolic link is diverted? What happens if the target
of an aliasing symlink itself is an aliasing symlink? In assuming that
files have one and only one canonical location, we are saved from this
complexity on multiple levels. Why do you see adding such complexity as
obviously correct?
The more I read your and Sam's mails, the more I have the impression
that I miss some important aspect.
Helmut
Reply to: