Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Online Repos Installation Workflow Steps #915

Open
shundhammer opened this issue Feb 24, 2021 · 5 comments
Open

Simplify Online Repos Installation Workflow Steps #915

shundhammer opened this issue Feb 24, 2021 · 5 comments
Labels
feedback Discussion or proposal (not a bug)

Comments

@shundhammer
Copy link
Contributor

shundhammer commented Feb 24, 2021

Simplify Online Repos Installation Workflow Steps

This is part of #903 (Make the installation process shorter).

In the installation workflow (#914), we have these steps:

Asking about Online Repos

inst-tw-040-ask-online-repos

Selecting Online Repos

inst-tw-050-online-repos

Problems

  • It's two steps (three if you also count the "Writing..." step where the user just has to wait)

  • One step would be totally sufficient (see below)

  • Most information in the second step is redundant (see below)

  • The second step is much too detailed. It suggests much more complexity than there really is.

  • Most users simply don't care: Just use the defaults.

@shundhammer
Copy link
Contributor Author

inst-tw-040-ask-online-repos

This is the important part, yet it's hiding in a small pop-up question.

I didn't test it, but when I go back in the workflow, will this pop up again? If not, that would break the logic and consistency of the wizard workflow.

@shundhammer
Copy link
Contributor Author

shundhammer commented Feb 24, 2021

inst-tw-050-online-repos

Why do we have this at all? A user who choses to use online repos will typically (I guess in 99.9% of all cases) simply leave the defaults. So why bother with this step?

There is not much you can do anyway, yet it looks awfully complicated. I guess we are just reusing the existing dialog from the repo management module here, but IMHO this is just overwhelming the user with too many details.

  • There will never be any more than the 5 repos displayed in this screenshot anyway. So there is no need at all for the "Filter" input field and button; they only add to the complexity of the dialog.

  • We cannot install source RPMs at all with the YaST package selector (we could prior to libzypp, but that functionality was never ported). That "Main Repository (Sources)" is not only redundant here, worse, it suggests a functionality that is not available; we are making a promise here that we cannot keep.

  • I don't think anybody will ever bother with debug packages during a base installation. IMHO this is redundant.

This leaves the two main repos: The update repo and the main repo. The update repo is the whole point of offering online repos here in the first place, so what good would it do to activate them and then NOT use updated packages?

Those "online repo" workflow steps will appear only if using the DVD ISO; for the net ISO, online repos are needed anyway because the ISO doesn't contain any repos. The "Main OSS" repo on the DVD ISO has either the same content as its online counterpart (same versions anyway), or it is a (large) subset of that online repo. But the attached DVD / USB stick will be much faster than a download; so I question the wisdom of activating that "Main OSS" online repo here.

The "Main Repository (Non-OSS)" might be one thing that a hardcore FOSS only user might want to change (deactivate), but I have doubts if that has the desired effect: When a non-OSS package is selected, libzypp will simply fall back to the repo on the DVD, so again this is suggesting a functionality that we do not deliver here.

There are (probably intentionally) no "Add" or "Edit" buttons to add even more repos or to change the ones that are offered, so everything in this workflow step is limited to the 5 (actually 4 because the "Sources" repo is pointless) repos here. The only useful thing that a user can do here is to activate or deactivate them all which is the exact same thing that we already asked in the first step.

So, what's the point of this workflow step at all? It is completely redundant. It serves no useful purpose.

@shundhammer
Copy link
Contributor Author

shundhammer commented Feb 24, 2021

So I suggest to be more honest and reduce all this to only the first step: Asking the user if online repos should be used.

We might consider to promote that to a full-fledged workflow step so "Next" and "Back" would be more transparent and would leave no question if going back would get a user here again.

My first impulse when I wrote this was to offer some details about the online repos so the question doesn't look so lonely, but that would again increase the complexity. If at all, a "Details..." button leading to this second step as a workflow branch would be the maximum.

---------------------------------------------------------

The system has an active network connection.
Additional software is available online.

(x) Activate online repositories
    [Details...]

( ) Use only the repositories on the installation media


[Help]                              [Abort]  [Back] [Next]
----------------------------------------------------------

@shundhammer shundhammer changed the title Simplify Online Repos During Installation Simplify Online Repos Installation Workflow Steps Feb 24, 2021
@lslezak
Copy link
Member

lslezak commented Mar 1, 2021

There will never be any more than the 5 repos displayed in this screenshot anyway

what's the point of this workflow step at all? It is completely redundant. It serves no useful purpose.

Well, it's a bit more complicated under the hood.

In Leap 15.2 (and very likely in 15.3 as well) there are also offered some 3rd party repositories like Packman, Libdvdcss or nVidia drivers. These are a bit problematic, we cannot add them automatically. Packman and Libdvdcss are problematic from legal POV (might be forbidden in some countries), the nVidia repository uses it's own GPG key and some people are reluctant to importing an external signing key into the system. More over it is pointless to install anything from there unless you really have an nVidia graphics card in the system.

Moreover that problematic repositories are defined in a 3rd party XML file (here, linked from here). That means it's out of our control and if the server gets hacked somebody could add some nasty repository or change the URL of some existing repository.

So for the security reasons we really need user confirmation for adding the repositories and the user really needs to know what is being added (at least the URL).

We could skip the selection dialog, but we would need to ensure that only the SUSE repositories are added. We cannot skip it unless there are some 3rd party repositories which are out of our control (or are legally problematic).

But I agree that we could remove some details in the dialog (like "Linked from", "Recommended") or move them elsewhere. For example the summary could be displayed directly into the repo list, like

[x] Main Update Repository - Official update repository for Tumbleweed

@ancorgs ancorgs added the feedback Discussion or proposal (not a bug) label Mar 16, 2021
@ahjolinna
Copy link

is there any progress/hope for this, as for mainstream enduser perspective having the ability to enable some of the 3rd-party repos would help a lot, especially "Cisco’s H264 codec" thing, Nvidia and then packman

I do hope this could be done, as small stuff like this would help gain more users, especially gamers who usually have latest nvidia gpu would really benefit from able to add nvidia drivers on installation.

also then there is the MicroOS (desktop) users, adding repos and installing stuff manually on it is more different and would probably turnoff more mainstream endusers than normally. Which is why I hope this could happen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback Discussion or proposal (not a bug)
Projects
None yet
Development

No branches or pull requests

4 participants