[opensuse] Is there a way to make yast2 package manager less verbose?

newer
[opensuse] Strange error in F-Spot

older
[opensuse] Command line list of...

Aniruddha

9 Oct 2007 9 Oct '07

12:40

With the yast2 package manager I have to confirm every dependency change. I would like to do this automatically (much like smart does) can this be done? and if so how? Thanks in advance! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Show replies by date

Stefan Hundhammer

9 Oct 9 Oct

12:44

On Tuesday 09 October 2007 14:40, Aniruddha wrote:

...

With the yast2 package manager I have to confirm every dependency change. I would like to do this automatically (much like smart does) can this be done? and if so how? Thanks in advance!

What can get done automatically is already being done automatically. The dependency problems you get to see are those that cannot be resolved automatically. Kind regards -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

12:47

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

Thank you for your answer. Do you happen to know why smart is able to make these dependency adjustments automatically? How can we implement this (as an option) in future yast2 version? On Tue, 2007-10-09 at 14:44 +0200, Stefan Hundhammer wrote:

...

On Tuesday 09 October 2007 14:40, Aniruddha wrote:

...
With the yast2 package manager I have to confirm every dependency change. I would like to do this automatically (much like smart does) can this be done? and if so how? Thanks in advance!

What can get done automatically is already being done automatically. The dependency problems you get to see are those that cannot be resolved automatically.

Kind regards -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Stefan Hundhammer

13:13

On Tuesday 09 October 2007 14:47, Aniruddha wrote:

...

Thank you for your answer. Do you happen to know why smart is able to make these dependency adjustments automatically?

Are you actually comparing the same scenarios? Dependency problems are something no user likes to be confronted with. So we try to resolve as many of them as possible. The ones that are left are the ones that get reported to the user. If we knew any reasonable way (that works in every case, not just in some) to handle them automatically, we would. Could you come up with some real dependency problems you were confronted with and with some suggestions how to handle them automatically? Hint: You can export the problem report to text file from that dialog's "Expert" menu button; you could paste the result here. This kind of discussion becomes very abstract really quickly without real examples. CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

15:18

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

Good point. You can see the difference for yourself by trying to remove alsa. Yast2 provides the user with lots of manual (and in my opinion unnecessary) choises to be made whilst smart does the same in 2 clicks. On Tue, 2007-10-09 at 15:13 +0200, Stefan Hundhammer wrote:

...

On Tuesday 09 October 2007 14:47, Aniruddha wrote:

...
Thank you for your answer. Do you happen to know why smart is able to make these dependency adjustments automatically?

Are you actually comparing the same scenarios?

Dependency problems are something no user likes to be confronted with. So we try to resolve as many of them as possible. The ones that are left are the ones that get reported to the user. If we knew any reasonable way (that works in every case, not just in some) to handle them automatically, we would.

Could you come up with some real dependency problems you were confronted with and with some suggestions how to handle them automatically? Hint: You can export the problem report to text file from that dialog's "Expert" menu button; you could paste the result here. This kind of discussion becomes very abstract really quickly without real examples.

CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

15:44

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

I have attached two examples, you can compare these with the way smart handles conflicts. My solution is simple; just automatically remove the conflicting files and let the user know you are doing that. Or provide sane default setting which can be easily agreed upon. On Tue, 2007-10-09 at 15:13 +0200, Stefan Hundhammer wrote:

...

On Tuesday 09 October 2007 14:47, Aniruddha wrote:

...
Thank you for your answer. Do you happen to know why smart is able to make these dependency adjustments automatically?

Are you actually comparing the same scenarios?

Dependency problems are something no user likes to be confronted with. So we try to resolve as many of them as possible. The ones that are left are the ones that get reported to the user. If we knew any reasonable way (that works in every case, not just in some) to handle them automatically, we would.

Could you come up with some real dependency problems you were confronted with and with some suggestions how to handle them automatically? Hint: You can export the problem report to text file from that dialog's "Expert" menu button; you could paste the result here. This kind of discussion becomes very abstract really quickly without real examples.

CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany

Stefan Hundhammer

11 Oct 11 Oct

11:42

On Tuesday 09 October 2007 17:44, Aniruddha wrote:

...

I have attached two examples

Please don't top-quote. This makes answering a real pain.

...

My solution is simple; just automatically remove the conflicting files and let the user know you are doing that. Or provide sane default setting which can be easily agreed upon.

I see what you mean. We had that once, but this is really something that is very dangerous and thus not desirable in most cases. The old package manager used to come up with a solution like "delete all conflicting packages" - getting rid of everything that depended on the package you marked for deletion. While this can be useful in some very few cases, in many more cases it will leave you with a wrecked system. Marked kdebase3 for deletion? The proposed solution would be to remove all packages that depend on it, which means all of KDE. OK, that might still be something that a few users might want every now and then. But we have more base packages whose purpose is not so obvious to the not-so-informed user. XML libs come to mind. While some users might think "I don't like or want to use XML", a lot of packages depend on it directly or indirectly. Of course, a "delete all depending packages" solution would include all indirect dependencies as well. You'd be amazed how much free space you'd have on your hard disk after that... Only you wouldn't have a working system any more. Well, not quite. Working - yes. It would have a kernel and a shell etc.; but you'd probably hate to use what would be left of your desktop. ;-) In the old (pre-10.1) package manager we offered that kind of solution. But frankly, it was never very useful. And those users who selected that probably had to reinstall the system in most cases. I don't think it's a good idea to reintroduce that kind of behaviour. It hurts more than it could possibly heal. CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

12:31

On Oct 11 2007 13:42, Stefan Hundhammer wrote:

...

...
My solution is simple; just automatically remove the conflicting files and let the user know you are doing that. Or provide sane default setting which can be easily agreed upon.

I see what you mean. We had that once, but this is really something that is very dangerous and thus not desirable in most cases.

Use smart, whereby `smart remove libxml2` will list all that is going to be deleted if you desire so. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Benji Weber

12:51

On 11/10/2007, Stefan Hundhammer wrote:

...

I see what you mean. We had that once, but this is really something that is very dangerous and thus not desirable in most cases.

The old package manager used to come up with a solution like "delete all conflicting packages" - getting rid of everything that depended on the package you marked for deletion.

While this can be useful in some very few cases, in many more cases it will leave you with a wrecked system.

Only if it is not made clear to the user. Currently the conflict resolution dialogue might display something like [ ] Do not install fooapp [ ] Remove barapp [ ] remove conflicting libbar [ ] change vendor of libfoo to <vendor> etc etc. The user is forced to make a decision, which will then force a new solver run, which might throw up another 10 or more issues that require manual intervention. It is indeed quite possible to even go round in loops, depending on which solutions the user chooses at each stage. This is very difficult for users who don't understand the package management internals. IMO a more preferable mode of operation to the user would be to perform a complete solver run and then propose it to the user, with the option to alter it if it's not correct. So where there is the option to remove a conflicting package/not install package/change vendor etc, the solver notes the choice and picks the most preferable version - e.g. vendor change is preferred over some other changes. If this choice does not lead to a solution the solver would have to backtrack & try one of the other solutions. Once an valid /complete/ solution is found it could be presented to the user as a summary: The following changes will be made: <Packages to be installed> <Packages to be removed> <Packages with vendor change> [ Accept ] [ Modify Proposal ] [ Cancel ] Obviously this is a lot more difficult to implement, but would be far more friendly. _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

13:02

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

On Thu, 2007-10-11 at 13:42 +0200, Stefan Hundhammer wrote:

...

On Tuesday 09 October 2007 17:44, Aniruddha wrote:

...
I have attached two examples

Please don't top-quote. This makes answering a real pain.

I am sorry, I really thought it was more convenient, after reading other posts on this mailing list I realized it wasn't. I even adjusted my signature ^_^

...

I see what you mean. We had that once, but this is really something that is very dangerous and thus not desirable in most cases.

The old package manager used to come up with a solution like "delete all conflicting packages" - getting rid of everything that depended on the package you marked for deletion.

While this can be useful in some very few cases, in many more cases it will leave you with a wrecked system. .... But we have more base packages whose purpose is not so obvious to the not-so-informed user. XML libs come to mind. While some users might think "I don't like or want to use XML", a lot of packages depend on it directly or indirectly. Of course, a "delete all depending packages" solution would include all indirect dependencies as well.

Why not include less verbose as an option? That way you can have it both ways. A default verbose mode for the inexperienced user and a less verbose with as default setting "delete all conflicting packages". It is a matter of presentation as well. Yast2 could also show a pop-up window showing in bright red letters the following text -------------------------------------------------------------------- REMOVING PACKAGE FOO MEANS THESE PACKAGES WILL BE REMOVED AS AS WELL package-lib/dependency package/very_important_package package/very_very_important_package DO YOU AGREE? YES/NO* *Go back and adjust package selection ------------------------------------------------------------------------------ That way it is much clearer for users which choices they do have. And More importantly you don't have to set them for each package individually. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

28 Oct 28 Oct

13:21

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

On Thu, 2007-10-11 at 13:42 +0200, Stefan Hundhammer wrote:

...

...
My solution is simple; just automatically remove the conflicting files and let the user know you are doing that. Or provide sane default setting which can be easily agreed upon. ... In the old (pre-10.1) package manager we offered that kind of solution. But frankly, it was never very useful. And those users who selected that probably had to reinstall the system in most cases.

I don't think it's a good idea to reintroduce that kind of behaviour. It hurts more than it could possibly heal.

The more I work with openSUSE the more I feel the dependency handling by zypper/yast2 really needs improvement. Updating becomes impossible for novices. Right now when I want to update I get the following error, it really is a shame that one has manually delete packages in order to fix dependency problems manually:

...

...
2 Problems: Problem: No valid solution found with just resolvables of best architecture. Problem: Cannot install wesnoth-data-base, because it is conflicting with wesnoth-data

...
Problem: No valid solution found with just resolvables of best architecture. With this run only resolvables with the best architecture have been regarded. Regarding all possible resolvables takes time, but can come to a valid result.

...
Solution 1: Make a solver run with ALL possibilities. Regarding all resolvables with a compatible architecture. number, (r)etry or (c)ancel>

-- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Kupec

13:59

Aniruddha wrote:

...

On Thu, 2007-10-11 at 13:42 +0200, Stefan Hundhammer wrote:

...
...
My solution is simple; just automatically remove the conflicting files and let the user know you are doing that. Or provide sane default setting which can be easily agreed upon. ... In the old (pre-10.1) package manager we offered that kind of solution. But frankly, it was never very useful. And those users who selected that probably had to reinstall the system in most cases.

I don't think it's a good idea to reintroduce that kind of behaviour. It hurts more than it could possibly heal.

The more I work with openSUSE the more I feel the dependency handling by zypper/yast2 really needs improvement. Updating becomes impossible for novices. Right now when I want to update I get the following error, it really is a shame that one has manually delete packages in order to fix dependency problems manually:

...
...
2 Problems: Problem: No valid solution found with just resolvables of best architecture. Problem: Cannot install wesnoth-data-base, because it is conflicting with wesnoth-data Problem: No valid solution found with just resolvables of best architecture. With this run only resolvables with the best architecture have been regarded. Regarding all possible resolvables takes time, but can come to a valid result.

...
Solution 1: Make a solver run with ALL possibilities. Regarding all resolvables with a compatible architecture. number, (r)etry or (c)ancel>

- enter '1' here - you'll get a solution proposal for the next problem - choose the solution number you like (probably 'remove wesnoth-data') hth Jano -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

14:34

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

n Sun, 2007-10-28 at 14:59 +0100, Jan Kupec wrote:

...

patible architecture.

...
...
...
number, (r)etry or (c)ancel>

- enter '1' here - you'll get a solution proposal for the next problem - choose the solution number you like (probably 'remove wesnoth-data')

hth

Jano

Thank you for your answer. Unfortunately when you do this you get stuck in an endless loop of answering questions: 2 Problems: Problem: No valid solution found with just resolvables of best architecture. Problem: Cannot install wesnoth-data-base, because it is conflicting with wesnot h-data Problem: No valid solution found with just resolvables of best architecture. With this run only resolvables with the best architecture have been regarded. Regarding all possible resolvables takes time, but can come to a valid result. Solution 1: Make a solver run with ALL possibilities. Regarding all resolvables with a compatible architecture. number, (r)etry or (c)ancel> 1 Applying solution 1 ...... Solution 1: do not install wesnoth-data-base do not install wesnoth-data-base-1.2.7-3.1.noarch[Games_Turn-Based] Solution 2: do not install wesnoth-data do not install wesnoth-data-1.3.9-12.1.noarch[Games_Turn-Based] Solution 3: Ignore this conflict of wesnoth-data-base number, (r)etry or (c)ancel> 1 Applying solution 1 ...... 8.1.x86_64[Games_Turn-Based] (wesnoth-data == 1.3.9) Solution 1: do not install wesnoth-data-full do not install wesnoth-data-full-1.2.7-3.1.noarch[Games_Turn-Based] Solution 2: do not install wesnoth-data do not install wesnoth-data-1.3.9-12.1.noarch[Games_Turn-Based] Solution 3: Ignore this conflict of wesnoth-data-full number, (r)etry or (c)ancel> 1 Applying solution 1 2 Problems: Problem: libgda-3_0 cannot be installed due to missing dependencies Problem: libgda-sqlite cannot be installed due to missing dependencies Problem: libgda-3_0 cannot be installed due to missing dependencies There are no installable providers of libgda-3.0.so.3 for libgda-3_0-3.1.1-13. .... Solution 1: do not install libgda-3_0 do not install libgda-3_0-3.1.1-13.1.i586[http://download.opensuse.org/reposit ories/GNOME:/STABLE/openSUSE_10.3/] Solution 2: Ignore this requirement just here number, (r)etry or (c)ancel> 1 Applying solution 1 Problem: libgda-sqlite cannot be installed due to missing dependencies .... Solution 1: do not install libgda-sqlite do not install libgda-sqlite-1.3.91-145.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] Solution 2: Ignore this requirement just here number, (r)etry or (c)ancel> 1 Applying solution 1 ..... Solution 1: do not install libgda-sqlite do not install libgda-sqlite-1.3.91-144.x86_64[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] Solution 2: Ignore this requirement just here number, (r)etry or (c)ancel> Applying solution 1 .... Problem: Marking resolvable gimp24-2.4.0-0.pm.2.x86_64[http://ftp.skynet.be/pub/packman/suse/10.3/] as uninstallable Solution 1: do not install gimp24 do not install gimp24-2.4.0-0.pm.2.x86_64[http://ftp.skynet.be/pub/packman/suse/10.3/] number, (r)etry or (c)ancel> 1 Applying solution 1 ....... Problem: Marking resolvable gimp24-2.4.0-0.pm.2.i586[http://ftp.skynet.be/pub/packman/suse/10.3/] as uninstallable Solution 1: do not install gimp24 do not install gimp24-2.4.0-0.pm.2.i586[http://ftp.skynet.be/pub/packman/suse/10.3/] number, (r)etry or (c)ancel> 1 Applying solution 1 ....... Problem: libtunepimp5-mp4 cannot be installed due to missing dependencies Solution 1: Install libofa although it would change the architecture libofa-0.9.3-60.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] provides this dependency, but would change the architecture of the installed item Solution 2: do not install libtunepimp5-mp4 do not install libtunepimp5-mp4-0.5.3-100.pm.7.i586[http://ftp.skynet.be/pub/packman/suse/10.3/] Solution 3: Ignore this requirement just here number, (r)etry or (c)ancel> 1 Applying solution 1 .......... Problem: libtunepimp5-mp4 cannot be installed due to missing dependencies Solution 1: do not install libtunepimp5 do not install libtunepimp5-0.5.3-100.pm.7.x86_64[http://ftp.skynet.be/pub/packman/suse/10.3/] Solution 2: Ignore this requirement just here Solution 3: Generally ignore this requirement number, (r)etry or (c)ancel> Applying solution 1 Problem: libofa cannot be installed due to missing dependencies There are no installable providers of libfftw3.so.3 for libofa-0.9.3-60.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] === libofa-0.9.3-60.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] === libofa-0.9.3-60.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] is needed by libtunepimp5-mp4-0.5.3-100.pm.7.i586[http://ftp.skynet.be/pub/packman/suse/10.3/] (libofa.so.0) fftw3-3.1.2-142.pm.3.i586[http://ftp.skynet.be/pub/packman/suse/10.3/] provides libfftw3.so.3, but another version of that package is already installed. Solution 1: do not install libofa do not install libofa-0.9.3-60.i586[http://download.opensuse.org/repositories/openSUSE:10.3/standard/] Solution 2: Ignore this requirement just here number, (r)etry or (c)ancel> etc. etc. etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

20:05

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

For comparison here's the output from smart upgrade which works without any user interaction: # smart upgrade Loading cache... Updating cache... ######################################## [100%] Computing transaction... Upgrading packages (150): OpenOffice_org-en-GB OpenOffice_org-icon-themes OpenOffice_org-nl OpenOffice_org-pt OpenOffice_org-templates-labels-a4 OpenOffice_org-templates-labels-letter SDL SDL-devel amarok amarok-libvisual amarok-xine amarok-yauap amsn amsn-skins avahi avahi-compat-mDNSResponder-devel basket clanlib clucene-core cmake compiz compiz-kde control-center2 dejavu devede eel ekiga evolution-data-server fftw3 freealut freeciv frozen-bubble ft2demos gimp glade glest glib2 glib2-devel glibmm2 gnome-keyring gnome-keyring-devel gnome-main-menu gnome-mount gnome-panel gnome-pilot gnome-pilot-lang gnome-themes gnome-utils gnome-vfs2 gnome-vfs2-devel gnumeric gnumeric-lang gstreamer010 gstreamer010-plugins-base gstreamer010-plugins-good gtk2 gtk2-devel gtkmm2 gwenview hal-palm k3b kaffeine kcm_gtk kio_iso koffice koffice-i18n-en_GB koffice-i18n-en_GB-doc koffice-i18n-nl koffice-i18n-nl-doc koffice-i18n-pt koffice-i18n-pt-doc ktorrent libavahi-devel libavahi-devel libbeagle libcroco libdns_sd libdns_sd libdts libgda libgda-lang libgnomedb libgnomedb-lang libgnomesu libgnomeui libgnomeui-devel libgsf libgsf-devel libgsf-gnome libkdcraw1 libnotify liboil libpisock-devel libpisock9 libpisync0 libpoppler-devel libpoppler-devel libpoppler-glib2 libpoppler-glib2 libpoppler-qt2 libpoppler-qt2 libpoppler-qt4-2 libpoppler2 libpoppler2 libqt4 libqt4-dbus-1 libqt4-devel libqt4-devel-doc libqt4-devel-doc-data libqt4-qt3support libqt4-sql libqt4-sql-sqlite libqt4-x11 libsigc++2 libtheora0 libtidy libtunepimp libtunepimp5 libxine1 libxine1-arts libxklavier libxklavier-devel libxslt libxslt-devel mjpegtools myspell-american myspell-dutch nautilus nspluginwrapper openal perl-spamassassin planner planner-lang pwlib python-gobject2 python-gtk qtcurve-gtk2 qtcurve-kde scummvm-svn spamassassin tidy virtualbox virtualbox-kmp-default wesnoth wesnoth-data wine wxGTK xdg-utils xmoto yelp Downgrading packages (2): digikam kipi-plugins Installing packages (25): SDL_gfx libavahi-core5 libmtp7 frozen-bubble-server libavahi-glib-devel libnotify1 gimp-lang libcroco-0_6-3 libode gnome-mount-lang libgda-3_0 libtunepimp5-mad graphviz libgda-3_0-3 libtunepimp5-mp4 gstreamer010-lang libgda-3_0-sqlite mad gwenview-lang libgnomesu0 nspluginwrapper-i386 kdemultimedia3-sound libgsf-1-114 ktorrent-lang libifp4 Removing packages (4): avidemux24 koffice-illustration kdegraphics3 trophy 453.5MB of package files are needed. 192.0MB will be used. Confirm changes? (Y/n): -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Cristian Rodriguez

12 Oct 12 Oct

09:48

Aniruddha escribió:

...

Thank you for your answer. Do you happen to know why smart is able to make these dependency adjustments automatically? How can we implement this (as an option) in future yast2 version?

it already do what you want, if it behaves the way smart do, it is a bug =) -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R. SUSE LINUX Products GmbH Research & Development -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aniruddha

09:43

New subject: [opensuse] Is there a way to make yast2 package manager less verbose?

On Tue, 2007-10-09 at 14:40 +0200, Aniruddha wrote:

...

With the yast2 package manager I have to confirm every dependency change. I would like to do this automatically (much like smart does) can this be done? and if so how? Thanks in advance!

Here is a really good example of the choices you get when trying to delete alsa-devel. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette

6029

Age (days ago)

6048

Last active (days ago)

List overview

Download

15 comments

6 participants

participants (6)

Aniruddha
Benji Weber
Cristian Rodriguez
Jan Engelhardt
Jan Kupec
Stefan Hundhammer