The benefit would be to allow automatic partitioning in less disk space
than "normal" recipes when you do not need a desktop environment. Only
biosgrub|esp, / and swap, no LVM, no separate /boot unless the
architecture requires it.
But that's nearly the same as the atomic recipe, isn't it?
I asked several times if there were intended use cases for built-in
recipes which could be used as guidelines, but I have not seen any clear
answer yet.
Probably since such guidelines are not trivial to formulate: much different
szenarios, a wide ranch of hardware and similar might result in a higher
amount of entries to choose from, and too much choices are not always an
advantage...
The /boot partition size is bigger than I expected in all LVM
case(...)
Just leave it as is, ignoring the 260MB difference?
IMO the difference is too big to be ignored. Also it makes the partition
reach its maximum size (768M -> 1GB) with any disk size. If you're going
that way, it would be more consistent to define a fixed size of 1GB in
the recipe to hide the issue.
I believe that the only real solution is to fix the lvm partition
minimum size in partman-auto-lvm as described above, even though it may
affect existing custom LVM/crypto recipes. Keeping bugs for
compatibility is not good.
First, this is again a trade-off here.
And we can assume, that when LVM is used, the disk space is not of minimal
size, thus having the boot partition a bit bigger does not matter in LVM
cases (or in other words: when LVM is used, /boot will most probably reach
its max size anyway (?) ).
I'm unsure if I consider this a bug...