@hailey It's there so system admin can make conscious case-by-case decisions without being limited by hard deps - so you can pull mdadm without a mail server, for example. Or so someone else can get rid of thin-provisioning-tools when they don't need them activated at boot 😉 But if you just blindly disable all recommendations you sure are going to have more such experiences as the one you went through today.

@dos I actually don't need the thin drivers activated at boot. but the design of the system is such that LV autoactivation is a one shot type deal. If the tools in the lvm2 package let you create fully working thin LVs which then break on reboot, that's clearly a bug, no?

@hailey That's why lvm2 package recommends the package that makes it work.

In general, packages "depend" on things they absolutely need, and "recommend" things they need to ensure full functionality. There are weaker dependencies in Debian as well, called "suggestions", and these aren't being installed by default.

"The Recommends field should list packages that would be found together with this one in all but unusual installations."
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

@dos but that package doesn't make it work, it works as-is without that package. I don't actually need any of those tools in that package to achieve what I need to do, I just need the right kernel module - which I might remind you, is not provided by thin-provisioning-tools either - available in the initrd for when the oneshot lvscan happens

@hailey What's calling lvscan in initrd?

But anyway - my point was that a Debian system is expected to have recommended packages installed and it's not being tested for cases where they're not.

Doesn't mean you can't report these things and get them improved, but you're sure going to stumble upon more issues like that this way.