* Andreas Hanke <[EMAIL PROTECTED]> [Jun 25. 2006 01:25]: > Hi, > > continuing an old thread... > > Andreas Jaeger schrieb: > > As discussed last week, I wanted to continue the discussion about the > > package management changes - but not concentrating on the real bugs > > we're fixing now but on general issues: > > Some thoughts: > > 1. libzypp does not offer the full functionality of the old > yast2-packagemanager. A simple look at the file list of the old > yast2-packagemanager RPM shows this: > > /usr/bin/genIS_PLAINcache > /usr/bin/installation_sources > /usr/bin/online_update > > online_update is gone and that's OK for me. rug replaces its > functionality, and there are alternatives available. But the other ones > are missing while needed: Their absense breaks the "Install package with > YaST" and "Add directory as a YaST source" features of kdebase3-SuSE. > > genIS_PLAINcache is probably obsoleted by createrepo.
Either this or use "rug mount" to directly access a directory of .rpm files. > But > installation_sources is not: It would be very nice to have a > replacement, a commandline tool for adding YaST sources that works > independently of rug. The ruby-zypp bindings are intended to fill this gap. > kdebase3-SuSE could be changed to use createrepo > instead of genIS_PLAINcache and the installation_sources replacement. > > Ideally, the installation_sources replacement would be called > installation_sources and support the same commandline syntax as the old > installation_sources. Was the old tool and its options sufficiently useful ? How do they compare to e.g. rug or smart ? > > In the case that this is not possible for whatever reason, wouldn't it > be better to remove the two buttons "Install package with YaST" and "Add > directory as a YaST source" from kdebase3-SuSE ASAP? There's already a bug open for this. > > 2. rug/zmd and YaST/zypp communicate by executing each other. When > adding a source to YaST, it executes rug to make sure that rug/zmd know > about it. And when using rug/zmd to add a source, zmd executes various > helper binaries from libzypp-zmd-backend. > > Isn't that very complex and fragile per se? Yes, it is indeed. :-( However, integration with the Mono 1.x environment forced this type of implementation. > Sure it's possible to fix > bugs in this area until it works for most people, but will it ever be as > integrated as the old solution without rug/zmd was? No, probably not. Thats why we want to foster zypp-based applications which show a better integration. > > Why does zmd access zypp by executing helper binaries instead of linking > it directly, maybe through zypp-sharp bindings? Because Mono 1.x presented some very high hurdles when linking to C (resp C++) libraries. > Why does YaST execute > rug instead of having rug/zmd read the sources directly from zypp? Sources (resp. Services/Catalogs in zmd speak) are handled differently within ZMD than within yast/zypp. A catalog (== yast 'source') is just one type of service in zmd. Additionally, zmd lives in a networked world with ftp or http(s) based catalogs, whereas YaST(zypp) support many more types (cd, dvd, nfs, smb, iso, ...). > Currently rug/zmd feel more like "added to the system and installed by > default" rather than "integrated into the system". Proper integration needs resources and experience. Novell has just started walking the 'integration path' for systems management. > > 3. In GNOME, RPMs are associated with zen-installer, which is fine. But > zen-installer installs only one RPM at a time. Selecting multiple RPMs > and installing them at once is not possible, but often needed to avoid > having endless install -> check dependencies -> install loops. Thats a bug and should be reported. > > Knowing that the answer will be "People should not download individual > RPMs and install them from nautilus, but add the installation source to > YaST or switch to smart or apt", I still think that usability > improvements should be considered in this area because more people have > the habit of downloading individual RPMs than you might think. We are listening, be assured. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
