[opensuse-factory] Zypper behaviour - install/update as many packages as possible? - openSUSE Factory

newer
[opensuse-factory] zypper activity...

[opensuse-factory] Zypper behaviour - install/update as many packages as possible?

older
[opensuse-factory] AMD 690G + SuSE...

Alex

3 Mar 2008 3 Mar '08

04:04

Hello, a few question concerning the new shiny zypper. Definitely, everything has been pretty fast since the new version has been introduced in factory. I begin to like it better than any other package management system I have tried for SUSE over the years. However, some strange things remain for me: 1. When doing a factory update, zypper always insists on updating a few packages which definitely are already installed in the newest version. E.g. for bash or perl-base (and quite a few other packages), zypper with every update reproducably installs the same version of this packages over and over again. 2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update. Thus every factory update takes much time to download, it takes unnecessary disk space, and basically makes handling a clean and up-to-date factory system a pain. Why should I as a non-developper need gdb? Or kdelibs-doc and PolicyKit-doc? Or Java 1.5 besides 1.6? Why do I need a complete 32bit KDE3 on my 64bit KDE4 system? And so on. I'm just complaining because right now a simple factory update on my lean system has resulted in an 1,9 GB / 3h download as proposed by YaST, simply because zypper deems it necessary to 1) re-install already installed packages with the same version and 2) install dozens of additional packages I don't need, and keep on deinstalling all the time. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Show replies by date

Stephan Kulow

3 Mar 3 Mar

08:36

Am Montag, 3. März 2008 schrieb Alex:

...

1. When doing a factory update, zypper always insists on updating a few packages which definitely are already installed in the newest version. E.g. for bash or perl-base (and quite a few other packages), zypper with every update reproducably installs the same version of this packages over and over again. There is a bug report about that one. It has nothing to do with the solver, but with the distupgrade algorithm.

...

2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update. Thus every factory update takes much time to download, it takes unnecessary disk space, and basically makes handling a clean and up-to-date factory system a pain.

You can lock the package, try man zypper

...

Why should I as a non-developper need gdb? Or kdelibs-doc and gdb = because the crash dialog will create a backtrace for you and why would you want to use factory if not to report bug reports if kde or gnome crashes?

kdelibs-doc = because you want documentation from KDE. This is not to be confused with kdelibs3-devel-doc, which is indeed only for developers.

...

PolicyKit-doc? Or Java 1.5 besides 1.6? Why do I need a complete 32bit KDE3 on my 64bit KDE4 system? And so on. 32bit KDE3 = because you might want to view flash sites.

...

I'm just complaining because right now a simple factory update on my lean system has resulted in an 1,9 GB / 3h download as proposed by YaST, simply because zypper deems it necessary to 1) re-install already installed packages with the same version and 2) install dozens of additional packages I don't need, and keep on deinstalling all the time.

The 1.9GB won't be dominated by kdelibs3-doc, but rather by packages being rebuilt as we checked in a new bash. We're still trying to find a good answer how to rebuild the distribution consistently and not requiring a 2GB download every week. And it's not zypper's fault, any correct package manager will have downloaded all these "same version" package - as they have a higher release. Beside bash and perl-base of course. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Alex

16:12

Am Montag, 3. März 2008 schrieb Stephan Kulow:

...

kdelibs-doc = because you want documentation from KDE. This is not to be confused with kdelibs3-devel-doc, which is indeed only for developers.

OK, got me there ;).

...

32bit KDE3 = because you might want to view flash sites.

This one I don't understand. 11.0 is KDE4 based, so I try to use KDE4 and consequently mostly KDE4 packages. KDE3 is only k3b, kmail and amarok. However, these packages require not only kdelibs3, but all the stuff from kdebase3-*. This seems to include a recommendation for kdebase3-nsplugin, which in turn on a 64 bit system starts the dependancy cycle once again for 32 bit libraries in order to be able to use flash. Am I getting this right?

...

The 1.9GB won't be dominated by kdelibs3-doc,

Yep, I was dramatizing it a bit ;). --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow

16:47

Am Montag 03 März 2008 schrieb Alex:

...

Am Montag, 3. März 2008 schrieb Stephan Kulow:

...
kdelibs-doc = because you want documentation from KDE. This is not to be confused with kdelibs3-devel-doc, which is indeed only for developers.

OK, got me there ;).

...
32bit KDE3 = because you might want to view flash sites.

This one I don't understand. 11.0 is KDE4 based, so I try to use KDE4 and consequently mostly KDE4 packages. KDE3 is only k3b, kmail and amarok. However, these packages require not only kdelibs3, but all the stuff from kdebase3-*. This seems to include a recommendation for kdebase3-nsplugin, which in turn on a 64 bit system starts the dependancy cycle once again for 32 bit libraries in order to be able to use flash. Am I getting this right? Yes, but this is not a zypper problem. k3b just required kdebase3 - but Stephan fixed that on friday.

Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Michael Schroeder

08:36

On Mon, Mar 03, 2008 at 05:04:44AM +0100, Alex wrote:

...

1. When doing a factory update, zypper always insists on updating a few packages which definitely are already installed in the newest version. E.g. for bash or perl-base (and quite a few other packages), zypper with every update reproducably installs the same version of this packages over and over again.

This sounds like a bug to me. AFAIK schubi is already working on it.

...

2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update.

That's actually the definition of "recommended", the solver should select it automatically. What's missing is that it is recorded somewhere that the user deselected the package afterwards. Plus, many packages that are marked as recommended should maybe be suggested instead, i.e. not automatically selected but displayed on an extra page. The trouble is, that extra page doesn't exist in YaST at the moment. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Alex

16:06

Michael Schroeder schrieb am 03.03.2008:

...

...
2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update. That's actually the definition of "recommended", the solver should select it automatically. What's missing is that it is recorded somewhere that the user deselected the package afterwards.

Yes, that would be a solution. Simply a switch that says "only update recommended packages if they are installed. If they are not installed, simply don't bother yourself and the user with them." The definition what is to be recommended for what kind of users is varying, I guess. I don't like getting recommandations getting forced onto me (note: ;) ), as this somehow blurs the distinction between "requirements" and "recommandations" in package management. In many cases I wonder why stuff is being divided up into different packages, only than to depend on/recommend each other...

...

Plus, many packages that are marked as recommended should maybe be suggested instead, i.e. not automatically selected but displayed on an extra page. The trouble is, that extra page doesn't exist in YaST at the moment.

That IMHO would be the optimum solution. I'd vote for that. However, if I see the speed jump with the latest version of zypper, I'm pretty optimistic that something simple like that will make its way into zypper, too. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stanislav Visnovsky

4 Mar 4 Mar

08:37

Dňa Monday 03 March 2008 17:06:17 Alex ste napísal:

...

Michael Schroeder schrieb am 03.03.2008:

...
...
2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update.

That's actually the definition of "recommended", the solver should select it automatically. What's missing is that it is recorded somewhere that the user deselected the package afterwards.

Yes, that would be a solution. Simply a switch that says "only update recommended packages if they are installed. If they are not installed, simply don't bother yourself and the user with them."

The definition what is to be recommended for what kind of users is varying, I guess. I don't like getting recommandations getting forced onto me (note: ;) ), as this somehow blurs the distinction between "requirements" and "recommandations" in package management. In many cases I wonder why stuff is being divided up into different packages, only than to depend on/recommend each other...

The whole idea of 'recommends' is that you are free to remove those packages.

...

...
Plus, many packages that are marked as recommended should maybe be suggested instead, i.e. not automatically selected but displayed on an extra page. The trouble is, that extra page doesn't exist in YaST at the moment.

That IMHO would be the optimum solution. I'd vote for that.

However, if I see the speed jump with the latest version of zypper, I'm pretty optimistic that something simple like that will make its way into zypper, too.

Please, don't mix different things. Speed is one thing, new solver features another one. Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Oddball

09:39

Stanislav Visnovsky schreef:

...

Dňa Monday 03 March 2008 17:06:17 Alex ste napísal:

...
Michael Schroeder schrieb am 03.03.2008:

...
...
2. Dependancies: Are there plans when a less greedy solver stragegy will be implemented? Right now, everything which is "recommended" will be installed, or pulled in when doing an update.

That's actually the definition of "recommended", the solver should select it automatically. What's missing is that it is recorded somewhere that the user deselected the package afterwards.

Yes, that would be a solution. Simply a switch that says "only update recommended packages if they are installed. If they are not installed, simply don't bother yourself and the user with them."

The definition what is to be recommended for what kind of users is varying, I guess. I don't like getting recommandations getting forced onto me (note: ;) ), as this somehow blurs the distinction between "requirements" and "recommandations" in package management. In many cases I wonder why stuff is being divided up into different packages, only than to depend on/recommend each other...

The whole idea of 'recommends' is that you are free to remove those packages.

...
...
Plus, many packages that are marked as recommended should maybe be suggested instead, i.e. not automatically selected but displayed on an extra page. The trouble is, that extra page doesn't exist in YaST at the moment.

That IMHO would be the optimum solution. I'd vote for that.

However, if I see the speed jump with the latest version of zypper, I'm pretty optimistic that something simple like that will make its way into zypper, too.

Please, don't mix different things. Speed is one thing, new solver features another one.

Stano

I want to admit my supportvote to implement a option to 'show recommended', and the option to leave them out, an the option to 'show deps'. As i noticed yesterday when i installed acrobatreader, tons of pkgs were being pulled in. To get rid of them afterwards is twice as inconvenient: Downloadtime, install, lookup, uninstall. Much unnessesary time lost. -- Enjoy your time around, Oddball (Now or never...) Besturingssysteem: Linux 2.6.24.1-6-default x86_64 Current user: oddball@AMD64x2-sfn1 System: openSUSE 11.0 (x86_64) Alpha2 KDE: 4.0.1 (KDE 4.0.1) "release 17" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Felix Möller

3 Mar 3 Mar

12:16

Hi,

...

a few question concerning the new shiny zypper. Definitely, everything has been pretty fast since the new version has been introduced in factory. I begin to like it better than any other package management system I have tried for SUSE over the years. Thanks to everybody involved in the development of zypper. The new version of zypper is certainly amazing.

Searching a package or calculating the dependencies improved by a factor of 10 at least that is my feeling. ;) Thanks alot, this will certainly make most people stop complaining about slow package management on openSUSE. greetings Felix Möller --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

5896

Age (days ago)

5897

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Alex
Felix Möller
Michael Schroeder
Oddball
Stanislav Visnovsky
Stephan Kulow