[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP 17: Improve support for directory aliasing in dpkg



Hello,

On Wed, 26 Apr 2023, Simon Richter wrote:
> > 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.
> 
> Yes, the relevant code at
> 
>     https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749
> 
> already handles moving a file inside the same package, and that has
> existed for some time, that's why I use two packages for the PoC.

Hum... why aren't we improving this part of the code?

We don't want to stat all the files in all packages but we could do better:
if we are about to remove an old file that is available through a
symlinked directory, we could check the new name of the file and see if
it's available in some package... and if yes just forget the file without
removing it.

This file removal is the reason of the moratorium and incuring some extra
cost in some specific cases (installation through directory symlinks which
is not the default case, and would not affect us after the migration is
complete) seems certainly fair.

The cost of analyzing directory components is a cost that we will have on
all dpkg invocations but it doesn't seem unreasonable to me. We could also
restrict it to the top-level directories to make it negligible as this
is the only transition that we care about here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS


Reply to: