Mailinglist Archive: opensuse-factory (279 mails)
| < Previous | Next > |
Re: [opensuse-factory] Package Management Design and Experience
- From: Klaus Kaempf <kkaempf@xxxxxxx>
- Date: Tue, 27 Jun 2006 13:41:50 +0200
- Message-id: <20060627114150.GA8102@xxxxxxxxxxxxx>
* Andreas Hanke <andreas.hanke@xxxxxxxxxxxxxx> [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
> 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
| < Previous | Next > |