Antoine Saroufim - 1:43 20.12.13 wrote:
Currently, we have a fair amount of software in the default
repositories that the user can utilize. If a user wants to install
software that isn't present in the default repositories, he/she can look
for it on OBS. The user can then proceed to add the targeted repository
to his/her system via 1-click install, zypper, or YaST2. The current
system works, but isn't quite perfect due to the following reasons:
- Users can't install packages not available in the enabled
If a user wants to install an application or library that isn't in the
default repositories, the user has to resort to searching for the
package on software.opensuse.org
through a browser and then installing
it or to installing OSC, searching for the package, adding a repository,
and then installing the package.
There used to be a YaST module to search and add stuff from OBS, but I guess it
was dropped at some point in time.
- Users may have to add many repositories to get all
Repositories on OBS may host a single desktop environment, a small
collection of apps, a single app, or even a patch. Over time, the user
might end up with a large number of repositories in order to keep all
his/her apps updated. Refreshing repositories might take longer every
time due to this and it might cause confusion. The user will have to
regularly check the enabled repositories and think of whether they are
needed or not. Refreshing a large number of repositories might also take
a while. Repositories can get deleted or altered often and the user will
have to modify them at each deletion/alteration. It's impossible for a
user to pick up the work of another user on certain repositories. Thus
the new maintainer will have to make a different repository.
Not really. In general if you have it in somewhere - not in home, anybody can
continue, send patches via OBS and there is project maintainer to act in case
package maintainer disappeared.
- Users might get confused when apps are offered by
Not all repositories are tagged and it might be difficult to tell which
repository has the most updated yet stable package. Zypper will warn the
user if the added repository and package will rewrite anything that is
already existing as it does whenever a vendor change is required.
However, users might not heed the warning and they might not be able to
tell if something actually works or not before installing it.
What we currently have is not a broken structure. On the contrary, our
current system works. However, even if it is not broken, and doesn't
require fixing, it can be improved. I'll further demonstrate the
limitations of the system by providing user cases.
- Daniel wants to install package XYZ. However, package XYZ is not in
the default repositories. Daniel goes to software.opensuse.org
searches for package XYZ but finds it listed under several repositories.
Some have higher version than others. Daniel wants the highest stable
version from a trusted repository. Which one of the repositories should
Not home and then it should be repository the package belongs to. Packages have
one repository they belong to, but might be linked to another one as
- Michael is a heavy gamer. He wants to play video
games on his desktop.
He adds games:tools to install Steam. He then proceeds to add Emulators
to install ZSNES, and finally adds games to install SuperTux2. However,
he notices that another game he wants is further updated on a home
repository and has to add that too. Michael ends up with having too many
repositories in order to get a few applications.
He shouldn't add home repository, he should ask that guy to push his stuff to
the main repository. Maybe we should hide home repositories even deeper in
software search to make people push their changes?
- Christine is a fan of music. She has thoroughly
tested most music
applications but is dissatisfied with them. She adds KDE:Extra in order
to update Clementine to a higher version, then downloads the .rpm of
Rhythmbox from Factory so she can install it without adding the repo,
and then adds GNOME:Apps to use an updated mplayer. Lastly, she adds
Geeko123's repo because he created his own music player and uploaded it
to his home project. One day, she wants to install Wayland dev packages.
Unknown to her, Geeko123 has added his own unstable Wayland packages.
Zypper pulls the Wayland packages from Geeko123's repo and Christine
ends up with a broken Wayland because she had assumed that Geeko123's
repo was solely for his music player and did not read the warnings.
Yes, we should go further with discouraging the use of home projects somehow. I
wonder whether this karmification idea can help us. Make it more visible who
contributes to the common pool of packages and doesn't just play with things in
As such, I propose the following improvements:
1 - Create larger repositories and merge similar ones together.
Partially done with Tumbleweed for stuff in the distribution. But I agree that
having one big repo for the rest that will not be frozen and more relaxed than
release is a good idea. Maybe revive Contrib with different purpose? If we get
a stable enough factory, we may even put it there. I think we would get more
contributors for this kind of repo than for a release as maintaining software
for years scares people (at least me).
2 - Create Community repository that is managed and
run by the
All of them are ;-)
- Add Reputation system. Installing packages from
the Community repo
can be a unsafe. However, if the uploader has been praised before, then
the user might feel more trusting. That way, the user will have a better
idea what is all right to install and what isn't. This will also give
motivation to people.
Yep, see karmification idea.
1 - Make zypper utilize smarter metadata.
Zypper can be updated to read all the metadata from all the
repositories and could suggest adding a repository if the desired
package isn't in the currently enabled repository. People should be able
to use zypper to find packages instead of having to resort to a browser
to search through OBS. This way, users can use gnome-software to access
all the software on OBS (in the future when a zypper plugin is written
I would say that it would be better if somebody stepped up and wrote again YaST
module for software.opensuse.org
. YaST is nowadays in Ruby, so it shouldn't be
that hard for somebody interested and skilled in Ruby :-)
2 - Visibly tag repositories to show their stability.
In order to help users choose the most stable repository, visible tags
should be provided to indicate the stability before the user adds the
Hard to judge the stability of repo, but what can be done with karmification is
show number of users which should be also helpful.
3 - Make repositories collaborative. By allowing
collaborative work we
may end up seeing less repositories in general. If person X creates repo
for package Y, person X is asked if repo is to be open for collaboration
to everyone. If person X decides to quit, another maintainer can pick up
the work on the same repository.
Done already ;-)
4 - Allow user to hide all "home"
I firmly believe that we should make everything simpler. It isn't a
matter of what can or can't be done, it's more about how easy it is to
get things done. By clearing confusion and allowing collaborative work,
we can help the users save precious time, give them an easier system,
and help them make better decisions. With front-end GUIs for package
managers, like Apper and gnome-software, on the rise, the traditional
method of installing software is changing. The shortest distance between
two points is a straight line. Thus, we should reduce the steps and
complications of installing and managing software in order to appeal to
more users and to further satisfy the ones we have. Improvement is what
keeps projects interesting. I for one do not want a system that works. I
want a system that works better than it did before. I hope you all
consider my suggestions before judging them and think of the average
users, not just of the advanced ones. Thank you for your time and I hope
we can keep this thread civil.
More like hide homes by default and add them once people ask for them. Like it
is by default in OBS. Something similar can be done in software search.
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org