Hi alaios.
Your question is a bit “ill formulated”.
By looking at your repositories you seem to have another problem:
what repositories fit my needs?
In substance:
Always there should be:
opensuse:
oss
no-oss
update
Then IMHO packman (with autorefresh).
A part of this:
how come that you use unstable repositories? You are a hardcore beta-tester and the machine is for testing new software? It doesn’t matter to you that the “barrack comes down” now and then? Well then it is perfectly fine.
Hold in mind that every time you use the “one-click” install, that repository is joint to the list (and should be taken off afterwards IMHO).
The videolan repository serves only to overcome the restricted format issue and can afterwards be removed. All the other needs of this aspects can be fulfilled with the packman repository.
The kde-community repo can sometimes give you some more “exotic” software and if you do not need it, do not put it.
The backport repo can cause you problems with overwriting packman kaffeine packages and similar (due to version numbering) and therefore you might prefer not to use it.
There are no trash repositories. But if you do not know what you want from your system you may well trash it.
This is most likely the result of using the one click install.
Now, as to what to keep. That really depends on you, but the essentials are OSS, Non-OSS, Updates, Packman. If you have Nvidia then you want the Nvidia repository as well. If you have ATI video card, then you want the ATI repository. Other than that, it is generally not a good idea.
Why?
It takes longer to load (refresh and load).
2)conflicts. Because different repositories will often have the same package but a different version or a different version scheme, this can trick the package manager into thinking that you have an obsolete package installed when you don’t. And other scenarios like that.
Remember; K.I.S.S. Not to be offensive but, Keep It Simple …
I have, before, managed over 120 repositories on my system, but then I write documentation for package managers. Even so, this gets extraneous and tiresome. I can sort through the dependencies, but most users can’t and don’t have that kind of time. It involves not just knowing package names and versioning and how they work, but it also involves understanding the contents of the package and how it will interact with other packages.