Hi initramfs-tools & cryptsetup maintainers,
initramfs-tools-core has:
Recommends: busybox (>= 1:1.22.0-17~) | busybox-static (>= 1:1.22.0-17~)
… which makes sense since initramfs-tools itself can work
without busybox.
But then indeed, the cryptsetup hook requires busybox. Still,
cryptsetup can be useful in some cases without busybox being
installed, so it has:
Recommends: busybox | busybox-static
So all the dependencies seem technically correct to me, it's "just"
that the resulting user experience is poor.
I see no obvious perfect solution. The options I can think of are:
1. Keeping things as-is:
- Affected systems: partial upgrades, systems where Recommends were
manually disabled; I don't think that full upgrades from Jessie
to Stretch are affected, since the initramfs is updated via
a dpkg trigger, after all packages have been upgraded.
In other words, only advanced users are affected.
- Impact: initramfs is not generated, and APT/dpkg exit with an
error message that tells the user what the problem is, and
suggests how to fix it.
2. Making initramfs-tools-core depend on a new enough busybox: pulls
busybox (installed size 746 kB, no dependencies besides libc6) even
on systems that don't need it, i.e. those that haven't cryptsetup
installed, and haven't busybox already pulled by anything else.
3. Making cryptsetup depend on a new enough busybox: pulls busybox
(installed size 746 kB, no dependencies besides libc6) even on
systems that don't need it; this growth impacts only systems with
Recommends disabled (otherwise they would already have busybox
installed) and systems that use another initramfs generator that
doesn't require busybox, such as dracut.
IMO option 3 is better than option 2:
* option 3 makes things worse than options 1 and 2 only in rarer cases
* busybox has greater chances to be needed when cryptsetup is
installed than when it's not
* initramfs-tools-core is installed even on relatively minimal
systems, while cryptsetup might not be
So at this point, I suggest this bug is reassigned to cryptsetup, and
option 3 is implemented there. But downgrading to non-RC and leaving
things as-is seems acceptable to me as well.
Thoughts?
Cheers,
--
intrigeri
