It is known that debootstrap first extracts packages without writting to dpkg database
using "dpkg-deb" or "ar" and then unpacks and configures packages using more high-level
methods.

I will refer to that low-level stage (when we extract packages using "dpkg-deb" or "ar") as
extract stage.

Manual page says: "--include=alpha,beta  Comma separated list of packages which will be
added to download and extract lists."

So, it follows from manual page that --include=alpha will add a package to set of packages,
which are extracted at extract stage. But experiment shows that this is not true. So,
please either fix debootstrap or its manual page.

Same for --exclude.

control: tags -1 +moreinfo

Hi,

 Please describe your expectation and the results since it's not
 clear for me.

Steps to reproduce:
* Get fresh sid system with debootstrap installed
* Run: debootstrap --include=aptitude --foreign sid /tmp/sid
* Then run: ls /tmp/sid/usr/bin/aptitude

I expected to see: /tmp/sid/usr/bin/aptitude

I see instead: ls: cannot access '/tmp/sid/usr/bin/aptitude': No such file or directory

I will state again that this bug can be fixed either by changing code, either by changing documentation.

I can explain problem another way, if you still don't understand.

==
Askar Safin
https://github.com/safinaskar

file or directory
code, either by changing documentation.

The problem here does not seem to be a bug but rather a failure on your
part to use debootstrap correctly, and/or a failure to understand what
to expect from the first stage of the two-stage execution model that
you have invoked, perhaps mistakenly, with your use of the `--foreign`
option.

If you tweak your example to simply remove the use of the `--foreign`
flag in step 3 then you should find that your `ls` command in step 4
works just fine.

It is important to understand what `--foreign` does if you're going to
use it and if you're to appreciate why your expectations are wrong
here. This option is meant for situations where you're building a
chroot for an architecture different to that of your host OS. What it
does is to prematurely stop the process after some initial work is
done, requiring you to pair this with a second execution using the `--
second-stage` option to have it complete the process. It's been a very
long time since I last looked at the code myself, but I believe that
I'm correct in saying that the first stage includes downloading all of
the packages and extracting a very minimal set of essential packages
necessary to making the second stage work, and that the second stage
then involves extracting / installing all remaining packages and
execution of package configuration scripts (which must be done using
the target architecture, apparently). More specifically, you would
typically not execute the second stage with the system/host copy of
debootstrap, but rather (via the `chroot` command) the copy placed in a
temporary location within the target directory you pointed debootstrap
at.

Normal usage model:
 - `sudo debootstrap --include=aptitude sid /tmp/sid`

Two-stage "foreign" usage model:
 - `sudo debootstrap --include=aptitude --arch=$ARCH --foreign sid /tmp/sid`
 - `sudo chroot /tmp/sid /bin/sh /deboostrap/debootstrap --second-stage`

(The `bin/sh` bit may be unnecessary, I'm copying from something that
does include that and I can't remember).

If you use debootstrap in this two-stage mode, and only do the first
stage, you cannot expect all of the packages to have been extracted,
nevermind that they would be in a usable state (with the configuration
stage of package installation having not yet been done), hence why it
is false to expect to be able to find your aptitude binary, and why it
would be even more wrong to assume that you could actually *run*
aptitude after just the first stage, if that's what you were wanting to
do.

To be fair, the documentation in the man page for `--foreign` says that
it causes debootstrap to only do the "initial packaging phase", which
could very easily mislead users into expecting that *every* package
would be unpacked during the first stage, which I am pretty certain is
not the actually case, so the documentation could benefit from being
improved.

I'm going to go ahead and close this, since there is no bug with the
functioning of `--include`/`--exclude` as you described. Feel free to
open a new bug to request improved clarification of the actions that
take place within each of the steps in the two-stage model.

control: reopen 935334

Hi, Lyndon Brown. It seems you don't understand what I mean, please, re-read bug report.

First of all, note on terminology, specially on word "extracting". I will use output of "debootstrap" tool itself as source of terminology. Look here, this is output of debootstrap: https://paste.debian.net/1210574/ . As you can see, debootstrap output uses word "extracting" in one very specific sense: "extracting" means extracting using "dpkg-deb" or "ar" at very early stage of debootstrap. Other actions have different names, for example, "unpacking". So, word "extract" means "extract using dpkg-deb or ar", this is different from "unpack using dpkg --unpack". So, I will use word "extract" in this sense.

Next. We know that --foreign causes early stopping of debootstrap. This stopping happens AFTER extracting stage (I use here word "extracting" in sense introduced above).

Next. Man page says: "--include=alpha,beta Comma separated list of packages which will be added to download and extract lists".

So, --include=aptitude should add aptitude to extract list, i. e. aptitude should be extracted at extract stage. --foreign runs extract stage, so --foreign should extract aptitude. But it doesn't. So man page (or debootstrap output or debootstrap itself) is wrong.

So, we anyway have a bug either in debootstrap implementation or in terminology used in its output or in manual page. I think we should fix the latter.

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

So how, exactly, does this cause an issue?