On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
> On 2021-07-27 Wouter Verhelst <wou...@debian.org> wrote:
> > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> >>> I've suggested previously that we can easily make it RC for bookworm to
> >>> have a file outside a limited set of directories (/etc and /usr would be
> >>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> >>> This is easy to detect with a lintian check and reasonably easy to
> >>> implement
>
> >> I don't think that works in general without breaking some of Debian's
> >> axioms around Essential packages, as previously described here:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
>
> > Yes. Those arguments didn't convince me then, and they don't convince me
> > now.
>
> > A package in the essential set could work around the issue by moving a
> > file around and creating a necessary symlink in preinst rather than
> > shipping things. The set of Essential packages is small however, and
> > most packages can ship a compat symlink.
>
> > I didn't say we *should* ship compat symlinks; I said we should make
> > antyhing that is *not* a compat symlink in a particular set of
> > directories be RC.
> [...]
>
> Hello Wouter,
>
> I will bite.
Cool.
> just for context: Simon said in #978636 that e.g. coreutils
> a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in
> the tarfile since /bin _might_ be a symlink to /usr/bin but
> b) it needs to provide /bin/mv in unpacked, unconfigured state.
>
> Simon then said we needed a flag day where the aliasing-symlinks /bin -->
> /usr/bin are either guaranteed to exist or forbidden. Once that is know
> essential packages either ship both /usr/bin/mv and /bin/mv (the latter
> a symlink) or only ship /usr/bin/mv (with no symlink required.)
>
> Afaiu you are suggesting to do somethink like this instead and
> immediately post bulleye release.
> ----------------------------------------
> preinst upgrade|install
> if aliasing-symlinks /bin --> /usr/bin
> # do nothing
> else
> mv /bin/mv /usr/bin/mv
That should be a copy (mv is too dangerous)
> ln -s /usr/bin/mv /bin/mv
This can be "ln -sf" to make it atomic.
> fi
> Plus corresponding error handling code in postrm abort install.
> ----------------------------------------
Yes, but for packages in the Essential set only. For other packages, we
can make it much simpler.
> I just do not get the benefit. It seems rather complicated with
> potential for breakage in corner cases and unnecessary since we (CTTE)
> have essentially decided that there is going to be a cutoff date
> pre-bookworm-release whereupon package maintainers can rely on the
> existence of aliasing-symlinks and can simply move the file without any
> maintainerscripts. It seems to be a waste of work to write
> complicated maintainerscripts that are only needed as long as we need to
> handle both usrmerge-d and non-usrmerge-d systems.
I'm not worried about the support for both usrmerge'd and not usrmerge'd
systems.
I'm worried about systems being written to completely bypass the dpkg
database. It's being pushed forward "because we broke things in the past
and now the only way to fix it is to break even more things". That's BS.
I'm convinced there is a way that we can move forward which does *not*
require bypassing the dpkg database. I think that such a way *should* be
preferential, and the complete lack of even a desire to discuss things
with the dpkg maintainer in ways that the dpkg maintainer thinks is a
reasonable way forward is distressing for me.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
