|
Bugzilla – Full Text Bug Listing |
| Summary: | Repositories tab in Package Manager doesn't show repositories that failed to refresh | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Tristan Miller <psychonaut> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED INVALID | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Tristan Miller
2017-01-16 10:20:00 UTC
We have two places where you can see the software repositories: - The "software repositories" YaST module where you can add, remove, enable/disable repositories or change their priorities - The "repositories" view in the package selector You are describing the behaviour in the package selector. That view intentionally does not show disabled repositories because the subsequent behaviour would be confusing: If disabled repos were listed there and the user would click on such a disabled repo, what should happen? The connected package list on the right side would still show the packages from that repo - or not? If a user tried to select such a package from a disabled repo, what should happen? Worse, if that package exists in several repos, including the disabled one (but also on one or more enabled repos), what should happen if the user selected such a package for installation or upgrade? Would he get the best one from one of the enabled repos - or, if the one from the disabled repos was the newest one, that one despite that repo not being enabled? This would introduce all kinds of confusion and inconsistencies; that's why those repos are *not* shown in that view. To get an overview over all repos, including disabled ones, please use the "software repositories" module. IMHO this behaves as intended -> INVALID (still a valuable contribution to discuss product features, of course). P.S. To see what packages you have on your system that are no longer part of any active repository, select a view that shows all (installed) packages, such as "installation summary" (and select only "installed" packages on the left side), then sort the package list by version numbers - voila, you'll get red packages first, then blue ones, then black ones; red meaning "orphaned" packages, i.e. those that are not or no longer in a repository, blue meaning packages that could be upgraded (i.e. there is a newer version) and black for the rest (most recent version already installed). IMHO that should cover your use case or at least most of it. Hi Stefan! I think you may have misunderstood some aspects of my report. (In reply to Stefan Hundhammer from comment #1) > You are describing the behaviour in the package selector. That view > intentionally does not show disabled repositories My report isn't about disabled repositories; it is about *enabled* repositories that (for whatever reason) failed to refresh. Most people don't disable such repositories right away, since it's not uncommon for the refresh to fail due to transient network or server problems. > because the subsequent > behaviour would be confusing: If disabled repos were listed there and the > user would click on such a disabled repo, what should happen? But I already suggested exactly what should happen: it should show installed packages from that repository, but hide the uninstalled ones. I think this is much less confusing and much more consistent than simply hiding both installed and uninstalled packages for that repository. (In reply to Stefan Hundhammer from comment #2) > P.S. To see what packages you have on your system that are no longer part of > any active repository, select a view that shows all (installed) packages, > such as "installation summary" (and select only "installed" packages on the > left side), then sort the package list by version numbers This isn't a full workaround, since I still can't see which packages came from which repository without selecting each one individually and examining it. (And it's not unheard of for multiple repositories to go AWOL at the same time. In the last few weeks both the Java and LibreOffice Factory repositories were moved.) The only full workaround I'm aware of, as mentioned in my report, is to use zypper from the command line. (In reply to Tristan Miller from comment #3) > Hi Stefan! I think you may have misunderstood some aspects of my report. > > (In reply to Stefan Hundhammer from comment #1) > > You are describing the behaviour in the package selector. That view > > intentionally does not show disabled repositories > > My report isn't about disabled repositories; it is about *enabled* > repositories that (for whatever reason) failed to refresh. Well, for the purpose of the YaST software selector they are disabled when they get to this state. This is what libzypp does internally. > Most people > don't disable such repositories right away, since it's not uncommon for the > refresh to fail due to transient network or server problems. > > > because the subsequent > > behaviour would be confusing: If disabled repos were listed there and the > > user would click on such a disabled repo, what should happen? > > But I already suggested exactly what should happen: it should show > installed packages from that repository, but hide the uninstalled ones. And this is exactly what not only would not work, it would be even more confusing to users since they would have to know how all this works internally. I can see that video player I installed from PackMan, yet it won't let me install the codecs from the same repo - the packages that I need to actually get it to work? That would be one of the possible results. > I think this is much less confusing and much more consistent than simply > hiding both installed and uninstalled packages for that repository. No, IMHO it isn't. It's a different kind of confusion, that's all. ;-) > (In reply to Stefan Hundhammer from comment #2) > > P.S. To see what packages you have on your system that are no longer part of > > any active repository, select a view that shows all (installed) packages, > > such as "installation summary" (and select only "installed" packages on the > > left side), then sort the package list by version numbers > > This isn't a full workaround, since I still can't see which packages came > from which repository without selecting each one individually and examining > it. For the red packages, you won't see a repo at all if it's not available. But you do see that you have something installed that isn't available anymore from any repo. > (And it's not unheard of for multiple repositories to go AWOL at the > same time. In the last few weeks both the Java and LibreOffice Factory > repositories were moved.) I don't argue that fact. But that's a completely different dimension; if the repo URL changes, that has to be tracked somewhere else. This is not typically done just for fun, but often enough for legal reasons, and this is where the user will have to make a decision if it's okay to go with the changed repo, or even to choose one if it turns out that an Open Source project forked and there are now several different ones. For typical network connectivity problems, however, the situation should get back to normal after a while. |