* Andreas Hanke <andreas.hanke@gmx-topmail.de> [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