On Tue, Mar 23, 2021 at 14:36:19 +0100, Michal Privoznik wrote: > On 3/22/21 5:09 PM, Tim Wiederhake wrote: > > virsh has several arguments that are better not used. This series introduces > > a formal way of marking them as deprecated. > > Commit messages are rather sparse. What we currently have is hiding options > we deem obsolete from users and replacing them with better ones (just :Ggrep > VSH_OT_ALIAS). No error message, no warning. What makes these you picked > special? I'm not against reporting that an option is obsolete, but I don't > quite understand why we need a different way for obsoleting those three. There's one exception seen in 5/5 and that is the 'base64' parameter of 'secret-set-value'. (It's not a boolean enabling base64 mode but rather a base64 value of the secret passed on the commandline). That option doesn't have an _ALIAS, but really shouldn't be used at all, thus we do print a warning. For this particular case we could consider hiding it, but it might be problematic as it doesn't use VSH_OFLAG_REQ_OPT, so is applied without the option name prefix [1] , which could be very misleading to users if it were hidden from the help output. Additionally for that particular case, printing a generic deprecation warning wouln'd IMO be enough as it's really a security issue, not just deprecation. [1]: $ virsh secret-set-value c021dc3e-8227-4bfa-8f1c-ebd0356fb872 YmxlCg== error: Passing secret value as command-line argument is insecure! Secret value set