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

Bug#1049898: marked as done (debootstrap: change /usr-merge implementation to merge after unpack)



Your message dated Fri, 18 Aug 2023 21:11:41 +0200
with message-id <20230818191141.GA1270361@subdivi.de>
and subject line Re: debootstrap: change /usr-merge implementation to merge after unpack
has caused the Debian Bug report #1049898,
regarding debootstrap: change /usr-merge implementation to merge after unpack
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1049898: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049898
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.128+nmu2
Severity: important
Tags: patch
Forwarded: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
X-Debbugs-Cc: bluca@debian.org, josch@debian.org, smcv@debian.org

Hi installer team,

we've had quite some discussion about various aspects of finalizing the
/usr-merge in the past half year. A rather late aspect of that is how to
move forward in a way that keeps debootstrap, cdebootstrap and
mmdebstrap working. That discussion mostly happened on d-devel@l.d.o and
was quite lengthy at times, but I think we've mostly reached agreement
on two important aspects. One aspect is that we'll be resolving the
remaining issues without reworking dpkg and rather shipping files in
their canonical (/usr) locations instead of aliased locations. When no
files are installed to aliased locations, much of the aliasing problems
in dpkg become irrelevant. The other aspect is that we want to ship the
aliasing symlinks in a package (base-files probably). The major benefit
of this approach is that once the symlinks are installed to some
data.tar, cdebootstrap and mmdebstrap will produce a merged layout
without changes. Unfortunately, this approach makes debootstrap fail
unpacking the relevant package shipping those links, because debootstrap
installs them ahead of unpack. It is this very failure that this bug
report addresses.

The proposal is that we swap the creating of aliasing symlinks and the
initial unpack. In doing so, unpacking base-files will not attempt to
overwrite the symlinks and debootstrap may skip the merging as it
recognizes the merged layout. The major downside of this approach is
that debootstrap actually has to perform a merge of the trees similar to
how the usrmerge package performs this change. A side effect of this
change is that debootstrap no longer needs a list of multilib
directories. Those that happen to be installed by transitively essential
packages will be recognized and merged and others won't be created. Long
story short, this implemented in the salsa MR mentioned above and has
been reviewed by Johannes, Luca and Simon. I've locally tested it with
buster, bullseye, bookworm and trixie.

I hope we don't get anymore disagreement with this and would like to
proceed with merging and uploading the change. Simon intends to backport
this change and
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93
to bookworm and bullseye via SPU. Getting that latter change into
bullseye is a prerequisite for converting buildd chroots to a merged
layout, which is a prerequisite for lifting the moratorium. In order to
avoid going through SPU multiple times, we'd like to do both changes at
once.

More background is available in the DEP17 draft. I've put up a rendered
version at https://subdivi.de/~helmut/dep17.html. In there, P8 is the
item concerned with debootstrap and M19 is the mitigation I am proposing
in this bug.

Is there any prerequisite you see missing before we can merge and upload
this change? Any aspect to be analyzed? Any situation to be tested? Any
conceptual aspect I am missing?

In the absence of a response, I intend to move forward with a delayed
NMU in accordance with devref, but I strongly appreciate more eyeballs
as this change is not without risks.

Helmut

--- End Message ---
--- Begin Message ---
Version: 1.0.130

Thanks to Luca for uploading.

Helmut

--- End Message ---

Reply to: