On Thu, 2020-01-30 at 14:16 +0100, Ladislav Slezak wrote:
Hi,
[..]
The question is how much is that add-on dependency information actually needed.
I mean if you need a package to install would any extra add-on dependency change your mind?
And even when the add-on dependency is known we cannot display the package dependencies. And that is very likely what the user really needs to know because a huge package dependency can change your mind.
Yes, I am not sure. If addons dependencies is not going to change your mind after all, we could just implement option 2).
I guess we have these options:
1) Do not display this information when working in an unregistered system. When the user clicks "Next", the base system should be registered and, at that point, we will get that info. Then we could display a "Summary" screen informing the user about the dependencies (before registering the modules/extensions).
Um, what if you decide to not continue after registering the base product?
Well, it might be a problem in cases like the Workstation Extension (you need a regcode). But, to be honest, I do not think it is a big issue.
2) Use a "Summary" screen for registered and unregistered systems. See the Alternative Workflow[3] description.
How actually the current workflow works? What if I search for package "foo" and select it to install, then I search for "bar" and select it to install. Finally I search for "baz" but I decide to NOT install it. Can I somehow see all what I have selected so far? If not then a summary dialog would be nice to have anyway.
No, you cannot see all that you have selected. So a summary screen would make sense.
3) Ask the SCC team to extend the API offering a list of available module/extensions including its dependencies. After all, they already provide a list of base produts through the API[4].
IMHO extending the SCC API is the correct solution for the problem, all other ideas are more or less just workarounds for that missing piece of information.
Sure, it might be the best solution. I just want to know if we *really* need it.
If you ask me, option 2) should be easy (and quick) to implement but it will change the current workflow. Is it better/worst than the current one? I am not sure (waiting for Ken's feedback).
Depending on the current workflow always displaying the summary might be good anyway.
+1
Option 3) might take more time (we will depend on SCC guys) and I would like to omit option 1).
If 3) is not possible (because of the external dependency) then I would choose 2).
OK, noted. Thanks for your feedback! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/