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/
signature.asc
Description: This is a digitally signed message part
