From 68dff04c4ead5ee6c3db66c689c2d0a07a15dfda Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 15 Oct 2017 13:01:49 -0400 Subject: forgot to add this comment --- .../comment_5_060b3ab57e525669c44192bbfdc730a4._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_5_060b3ab57e525669c44192bbfdc730a4._comment diff --git a/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_5_060b3ab57e525669c44192bbfdc730a4._comment b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_5_060b3ab57e525669c44192bbfdc730a4._comment new file mode 100644 index 00000000..2578ef8e --- /dev/null +++ b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_5_060b3ab57e525669c44192bbfdc730a4._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2017-10-04T17:12:59Z" + content=""" +Not sure why unpropelling blocks this. IIRC we discussed using a regular +propellor chroot to set up the sbuild chroot. And I pointed out that when +propellor runs inside a chroot, it does it without installing any +dependencies into the chroot; everything propellor needs to run is +bind mounted into /usr/local/propellor in the chroot. + +So, the most an "unpropell" property would need to do in a chroot is to +unmount below /usr/local/propellor and remove that directory, which should +then be empty. This might be desirable to be sure that the sbuild +environment is 100% clean, in the unlikely chance that something +builds differently when /usr/local/propellor exists. +"""]] -- cgit v1.2.3