Hi, Quoting Benjamin Drung (2020-01-10 17:43:49) > > the reason I deactivated hooks for --dry-run is, that hooks are able to do > > arbitrary stuff and when specifying --dry-run one probably does not expect > > something meaningful to happen. With hooks you could shoot yourself in the > > foot. I'm not strongly against allowing users to shoots themselves in the > > foot, so another reason to disable them was, that it is then possible to > > just add --dry-run to any command line (even including --hook options) and > > have the result just work without errors and without the user having to > > adjust the whole command line. But your example is a good argument to > > actually leave hooks be and expect the user to handle whatever they do. > > Executing the hooks in --dry-run has more drawbacks than benefits, > because simple commands in the hooks would become much more complex. > Because every invocation needs to learn the dry-run mode.
this is assuming that the user of mmdebstrap --dry-run does not just remove the
hooks altogether before adding --dry-run.
> How about adding --customize-hook-dry-run (etc.) and only execute those in
> dry-run mode? Then the users can decide on their own which hook needs a
> dry-run equivalent.
I think that would be too complex. If a user wants special hook A to be
executed in --dry-run mode and hook B in normal mode, then they would just
execute:
mmdebstrap --dry-run --hook A ...
mmdebstrap --hook B ...
I don't think it makes sense to move the logic into mmdebstrap.
> > This would not work anyways with --dry-run because you cannot chroot as the
> > directory does not contain any binaries.
> >
> > In case you care: a much cleaner and robust way than the above fragile
> > grep/cut/sed to answer questions like "what would apt install" or "what are
> > dependency chains to this package" are to use apt's ability to rely on
> > third party solvers. You would pass apt your own EDSP script which would
> > intercept the communication between the apt frontend and the solver backend
> > and would then be able to parse the EDSP easily because it is in a format
> > similar to deb822.
>
> Thanks for the pointer. I wasn't aware of doing that. Do you know any
> example third party solver doing that? Is it possible to add this hook
> to the apt call of mmdebstrap (and only to the apt call that installs
> the remaining packages)? If that is possible, then I don't need the
> dry-run hook support.
you would not replace the solver because you want to replicate the behaviour of
the apt solver. What you would do instead is to write a wrapper for the apt
solver that records the input and output in EDSP format and then uses deb822
aware tools like grep-dctrl to work with it. No regexes or other heuristics
needed then. You don't even need hooks, because in dry-run mode, apt is never
run inside the chroot, so you never need to put anything into it anyways. Here
is an example. Suppose you have a directory /tmp/mysolver and then put the
following script into /tmp/mysolver/mysolver and mark it as executable:
#!/bin/sh
set -exu
i=0
while [ -e /tmp/mysolver/$i ]; do i=$((i+1)); done
mkdir -p /tmp/mysolver/$i
cat > /tmp/mysolver/$i/input.edsp
cat /tmp/mysolver/$i/input.edsp | /usr/lib/apt/solvers/apt | tee
/tmp/mysolver/$i/output.edsp
for aptid in $(grep-dctrl '' /tmp/mysolver/$i/output.edsp -s Install
-n); do
grep-dctrl --exact-match --field APT-ID $aptid
/tmp/mysolver/$i/input.edsp
done > /tmp/mysolver/$i/output.pkglist
And then you run mmdebstrap like this:
./mmdebstrap --mode=fakechroot --debug --dry-run \
--aptopt='apt::solver "mysolver"' \
--aptopt='Dir::Bin::solvers "/tmp/mysolver"' \
--variant=essential --include=linux-image-amd64 \
unstable debian-unstable.tar
Then in /tmp/mysolver/0/output.pkglist, /tmp/mysolver/1/output.pkglist and
/tmp/mysolver/2/output.pkglist you will find machine readable deb822 files
containing all packages that apt installed in each of the three times that it
was executed.
Thanks!
cheers, josch
signature.asc
Description: signature
