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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
