Marcel Hilzinger schrieb:
I also think, that removing the package manager from YaST is a good idea. yast and yast2 makes a lot of work.
Oh no, please don't even consider doing that! First, this is not possible at all because the YaST2 package manager is needed during the installation. Not having a full-featured package manager there is possible, certain other Linux distros do it that way, but IMHO this is a real plus of SUSE Linux over other distros and should not be dropped. Users should be able to customize their system right from the initial installation, a full-featured package manager is needed for that purpose. And second, the YaST2 package manager is so much more comfortable than other approaches that losing it would be a pity. It's not only comfortable, I'd almost call it "luxurious": - I don't know any other package manager that provides almost the same, familiar UI in console and graphical mode. - I don't know any other package manager that provides easy access to almost every information about a package, even including the %changelog. - I don't know any other package manager that provides a comparable interface for resolving conflicts. Most other implementations just offer removal of the conflicting packages instead of offering alternative solutions. No removal of sw_single, please.
With a good commandline tool, there is no need for yast-pm in console mode. It's too much work.
A rug-like commandline tool is substantially different from sw_single in console mode. sw_single provides the same UI that users already know from sw_single with Qt frontend, rug doesn't. Using sw_single in console mode, people who are familiar with sw_single's Qt frontend can repair a broken system (e.g., X unintentially uninstalled or similar) without getting started with something completely different first. Both should be provided. A rug-like commandline tool *and* sw_single for the console. Their purpose is so different that replacing one of them with the other is impossible.
Let's make (rug) the best commandline tool, and then give rug two frontend-families: zen-installer for newbies, (please one tool, not intstaller and remover) and zen-updater a new qt/gtk-frontend with full installation source management, selections etc
But why a new qt/gtk frontend if sw_single already exists? Implementing it with in a widget set for X would be a loss of functionality compared to sw_single, which already has Qt and curses frontends. And implementing it both for X and curses would be a duplication of effort already put into sw_single. I seriously disagree with the idea that a full-featured, quasi-graphical package manager that works without X is superfluous. Andreas Hanke