Comment # 9 on bug 1203027 from Richard Brown

(In reply to Ancor Gonzalez Sosa from comment #8)
> BEWARE: philosophical conversation/digression ahead (not really useful to
> get the main issue addressed).
> 


> In the TPM2 example, is not that YaST decided to use a password instead of
> TPM2 for LUKS2 unlocking. It's simply that using a passphrase is the only
> way YaST knows. So the user cannot "correct" the proposal to use a different
> unlocking mechanism, even if that is something that can perfectly be done
> manually. We are not talking about the automatic proposal choosing the wrong
> option, we are talking about YaST limitations and lack of features. 
> 
> In the same way, subvolumes in YaST have been historically limited to just
> be mounted below its file-system according to the path of the subvolume (so
> they are treated as subdirectories on steroids). It has been like that since
> Btrfs was introduced in the distribution. YaST has never offered the
> possibility to adjust the mount point or the mount options of a subvolume in
> a completely independent and arbitrary way. Cannot be done with the Expert
> Partitioner, cannot be done with AutoYaST, cannot be configured in the
> control file and, of course, the installer cannot propose it automatically.

Except..YaST doesn't mount the subvolumes according to the path of the
subvolume
The path of the default subvolumes is /@/$foo

YaST isn't mounting them as /@/$foo for all the default subvolumes, but doing
some magic to mount them all as /$foo

This magic _CAN_ be configured by the control file by the following variable

<btrfs_default_subvolume> (usually @)

subvolumes $foo are defined by the <subvolumes> and <subvolume> parameters

YaST then does its magic munging <btrfs_default_subvolume> and <subvoulmes>
together to make its automatic proposal...and if users don't like it..users be
damned.. 

This is why I consider this bug a bug and not a feature request.

> 
> > The fact that YaST is auto-calculating mount points for subvolumes and not
> > giving users a chance to correct any mistakes and/or set mount points for
> > any additional subvolumes sure still feels like a bug to me that runs
> > counter to how we typically do everything else in YaST...
> 
> I disagree with reasoning done to get to the idea that the current subvolume
> handling goes counter to how we do things in YaST (already explained).
> Having said that, I don't think it makes a big difference calling it a bug
> or a (lack of) feature. That doesn't change the fact that allowing totally
> arbitrary mount points (and mount options) per subvolume implies changing
> the whole historical approach of YaST to subvolumes. That means deep changes
> would be needed in YaST. Changes in the user interface, changes in the
> AutoYaST schema and, of course, internal changes.
> 
> We really want to improve that part, but sadly we have not found time in the
> last couple of years because the people who sets the priorities always had
> something more pressuring.