February 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306933] Integrate Social Desktop into our Desktop
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: Michael Löffler (michl19) Feature #306933, revision 1 Title: Integrate Social Desktop into our Desktop openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Michael Löffler (michl19) Description: Social interaction between people becomes more important than ever. Communicating over the Internet via mails, forums and internet platforms is just normal. Just think of Facebook, Flickr, BitTorrent... One of the strongest assets of the free software community is its worldwide community of contributors and users who believe in free software and who work hard to bring the software and solutions to the mainstream. Core idea of the Social Desktop is to connect to your peers in the community, making sharing and exchanging knowledge easier to integrate into applications and the desktop itself. The concept behind the Social Desktop is to bring the power of online communities and group collaboration to desktop applications and the desktop shell itself. This feature is about the integration of such a social desktop into our desktop. If integrated it should be simply to use its functionalities but everybody needs to have free choice to use it or not. The targetgroup of the new community / social network is not only developers but also the end users who are not familiar with technical stuff and can with an integrated social desktop get easily in contact with people in the same area or people with same interests or software issues. Creation of some kind of facebook for openSUSE may stimulate the openSUSE adoption and bind existing users to the distribution. This could be beneficial for the marketshare of openSUSE. Another aspect is that this kind of communities can transform users into contributors. References: http://www.open-collaboration-services.org/ http://www.opendesktop.org -- openSUSE Feature: https://features.opensuse.org/306933

1 4

[openFATE 308184] canon dr 2080 c dokument scanner driver
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: Veit Mischel (vminov) Feature #308184, revision 1 Title: canon dr 2080 c dokument scanner driver Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Veit Mischel (vminov) Description: It is possible to write a driver for canon dr 2080 c document scanner . This scanner could be controlled over scsi card or usb. -- openSUSE Feature: https://features.opensuse.org/308184

1 1

[openFATE 307753] Share files with others remotely - Dropbox by default
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: Rastislav Krupansky (ra100) Feature #307753, revision 1 Title: Share files with others remotely - Dropbox by default openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Rastislav Krupansky (ra100) Description: Seeing that openSUSE is focusing on social networks, or the web applications like YAST elements - WebYAST, i think it would be great to offer something for synchronization files, sharing and work with others remotely. I think good choice might be Dropbox, which is multiplatform. Nautilus has already extension - nautilus-dropbox, but i don´t know whether any plugin is available under Dolphin, XFCE, etc.. I haven´t found yet. The one of ways could be here - http://antrix.net/journal/techtalk/dropbox_kde.comments -- openSUSE Feature: https://features.opensuse.org/307753

1 3

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 09 Feb '10

09 Feb '10

Feature changed by: Michael Löffler (michl19) Feature #305317, revision 25 Title: Default to hidden bootloader menu openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-08-05 12:17:52 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #9: Jan Engelhardt (jengelh) (2009-08-09 14:38:47) (reply to #6) (Well I had hoped you know ;-) What Fedora does (or what it used to in the last years, or what other distros did/do) is that the first GRUB screen does not show the menu (it's "hidden"), but only shows it if you interrupt with a keypress: http://www.dedoimedo.com/images/computers/fedora-first-boot.jpg --1st screen with "HIDDEN MENU" http://fedoraproject.org/w/uploads/d/d4/Tours_Fedora9_001_Install_Boot.png -- 2nd screen And FWIW, I find that rather pointless, just show the menu, does not hurt anybody to know a bit more about one's own system. #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? #10: Robert Davies (robopensuse) (2009-12-10 17:53:20) GRUB2 defaults to this method. How does this speed boot time though? If you wait for the user to give them a chance to activate the Hidden menu, you actually slow things up, as they are not encouraged to hit <enter>. I think having option hidden, makes it less obvious and increases documentation and support workload, because greater need for user education. Also the kernel does not give good user feedback early in boot process, seeing menu flash up reassures end user that things are working as expected. #11: Jan Engelhardt (jengelh) (2009-12-12 14:29:27) (reply to #10) Indeed, the switch time from the hidden state to showing the menu entries is considerable (and part of that is because it uses VESA). GRUB's text mode hidden feature (for serial consoles) is faster ;) -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[New: openFATE 308970] yast bootloader module: allow to set "default to last used" partition
by fate_noreply＠suse.de 09 Feb '10

09 Feb '10

Feature added by: Maciej Pilichowski (truemacias) Feature #308970, revision 1 Title: yast bootloader module: allow to set "default to last used" partition openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Maciej Pilichowski (truemacias) Description: The wish -- please use this feature in GUI (Yast/Qt), my suggestion is to put a checkbox next to "set default" button. The default partition with checkbox enabled would mean "initially default". But it was only a suggestion, a wish is -- provide GUI for this feature. Currently you have to set this or that partition to be the default. But it would be useful to set it in dynamic mode instead of static -- i.e. so the system would by default try to start from partition last used. Let's say I have two systems: Windows Linux Then I would be able to set as default: a) windows (static) b) linux (static) c) last used (dynamic) That way if I work this week in linux, and next one in windows, I would only have to start windows once, and next time it (grub) would start with windows as default boot. Original report: https://bugzilla.novell.com/show_bug.cgi?id=577793 -- openSUSE Feature: https://features.opensuse.org/308970

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 09 Feb '10

09 Feb '10

Feature changed by: Karl Eichwalder (keichwa) Feature #306404, revision 39 Title: Provide access to manuals openSUSE-11.2: Rejected by Gary Ekker (michl19) reject date: 2009-12-10 16:21:53 reject reason: 11.2 is past Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Furthermore, the manuals are not accessible directly from the media (the start-up guide being the sole exception), so one can only use them after having installed the system. Therefore providing Installation an Quickstart Guide is kind of absurd. I propose to host the PDFs under /docu in all repositories and create "empty" RPM packages just copying the PDFs from there. Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) I added SP1 - I know this is a late feature, and I should file such requests. Sorry. Let us please have some improvement to the current situation in SP1. Minimum effort for SP1 is adding appropriate desktop files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers #10: Juergen Weigert (jnweiger) (2009-12-04 15:24:27) Karl, Stefan pointed me to /work/SRC/all/sled-gnome-cbt_en/ *.spec cbt. desktop implements an icon on the GNOME desktop. Is this helpful? Are *. desktop files menat to be KDE or GNOME specific... ? :-( #13: Karl Eichwalder (keichwa) (2009-12-07 10:18:31) (reply to #10) Putting Icons an the desktop is something different. .desktop files are general (see freedesktop.org) but vendor enhancements are possible. Maybe, we should split theis feature. ATM, I do not understand what we want to achieve. On the GNOME desktop (SLED 11 SP1a2), if you click "Computer" > "Help", "SLED Documentation (en)" is listed. If you click on it, the HTML flavor of our docs is shown. You can see something similar on openSUSE. This, at least, is a start. Not sure, what needs to be done on KDE, though. #11: Jan Engelhardt (jengelh) (2009-12-05 13:50:14) This looks solved to me -- openSUSE 11.2 installs openSUSE-manual_en- pdf by default, even for a Minimal install chosen in yast. #12: Karl Eichwalder (keichwa) (2009-12-07 09:50:36) (reply to #11) openSUSE-manual_en-pdf is just a meta package. #14: Barry Nichols (barry_nichols) (2009-12-07 12:48:39) I consider myself to be a regular user and I found the manual pdfs easily enough. #17: Karl Eichwalder (keichwa) (2010-01-22 13:55:31) (reply to #16) Yesterday, I submitted new doc packages for SLE11 SP1. Check on beta3, whether the implementation is fine. + #20: Karl Eichwalder (keichwa) (2010-02-09 09:51:15) (reply to #17) + HTML of the SLED manuals is visible in yelp. + HTML of the SLES manuals are _not_ visible in KDE helpcenter. I need + info what is required for KDE4. + On SLED, the .desktop files for the PDFs are still missing. I'll try to + create those for yelp. Not sure, how this would work in KDE4. #18: Stephan Kulow (coolo) (2010-02-08 11:21:22) I still fail to see what's left to do for 11.3 + #19: Karl Eichwalder (keichwa) (2010-02-09 09:46:44) (reply to #18) + On 11.3 (and even 11.2 plus updates), it is probably fine. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 307200] Replace ifconfig by iproute2 - add warning messages to old tools
by fate_noreply＠suse.de 08 Feb '10

08 Feb '10

Feature added by: Jan Engelhardt (jengelh) Feature #307200, revision 1 Title: Replace ifconfig by iproute2 - add warning messages to old tools openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jan Engelhardt (jengelh) Description: Because Novell once again cannot be convinced, I am putting https://bugzilla.novell.com/show_bug.cgi?id=492665 to public vote here. net-tools (/sbin/ifconfig, /sbin/route, arp, etc.) has numerous problems, not to mention that it is not developed since April 2001 anymore. Since April 2004, iproute2 is available as a replacement for ifconfig, but users still use the old tools with the seemingly-crippled functionality. I propose printing a warning message upon invocation to try and educate users to finally use the modern tools. -- openSUSE Feature: https://features.opensuse.org/307200

1 7

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 08 Feb '10

08 Feb '10

Feature changed by: Stephan Kulow (coolo) Feature #306404, revision 38 Title: Provide access to manuals openSUSE-11.2: Rejected by Gary Ekker (michl19) reject date: 2009-12-10 16:21:53 reject reason: 11.2 is past Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Furthermore, the manuals are not accessible directly from the media (the start-up guide being the sole exception), so one can only use them after having installed the system. Therefore providing Installation an Quickstart Guide is kind of absurd. I propose to host the PDFs under /docu in all repositories and create "empty" RPM packages just copying the PDFs from there. Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) I added SP1 - I know this is a late feature, and I should file such requests. Sorry. Let us please have some improvement to the current situation in SP1. Minimum effort for SP1 is adding appropriate desktop files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers #10: Juergen Weigert (jnweiger) (2009-12-04 15:24:27) Karl, Stefan pointed me to /work/SRC/all/sled-gnome-cbt_en/ *.spec cbt. desktop implements an icon on the GNOME desktop. Is this helpful? Are *. desktop files menat to be KDE or GNOME specific... ? :-( #13: Karl Eichwalder (keichwa) (2009-12-07 10:18:31) (reply to #10) Putting Icons an the desktop is something different. .desktop files are general (see freedesktop.org) but vendor enhancements are possible. Maybe, we should split theis feature. ATM, I do not understand what we want to achieve. On the GNOME desktop (SLED 11 SP1a2), if you click "Computer" > "Help", "SLED Documentation (en)" is listed. If you click on it, the HTML flavor of our docs is shown. You can see something similar on openSUSE. This, at least, is a start. Not sure, what needs to be done on KDE, though. #11: Jan Engelhardt (jengelh) (2009-12-05 13:50:14) This looks solved to me -- openSUSE 11.2 installs openSUSE-manual_en- pdf by default, even for a Minimal install chosen in yast. #12: Karl Eichwalder (keichwa) (2009-12-07 09:50:36) (reply to #11) openSUSE-manual_en-pdf is just a meta package. #14: Barry Nichols (barry_nichols) (2009-12-07 12:48:39) I consider myself to be a regular user and I found the manual pdfs easily enough. #17: Karl Eichwalder (keichwa) (2010-01-22 13:55:31) (reply to #16) Yesterday, I submitted new doc packages for SLE11 SP1. Check on beta3, whether the implementation is fine. + #18: Stephan Kulow (coolo) (2010-02-08 11:21:22) + I still fail to see what's left to do for 11.3 -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 303460] Redesign of Sound Card Module
by fate_noreply＠suse.de 08 Feb '10

08 Feb '10

Feature changed by: Stephan Kulow (coolo) Feature #303460, revision 24 Title: Redesign of Sound Card Module openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-26 16:04:06 reject reason: Out of time for 11.0. Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-25 15:09:08 reject reason: Postponing, out of focus. Priority Requester: Important openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 10:52:29 reject reason: no volunteers and no resources Priority Requester: Important Projectmanager: Desirable - openSUSE-11.3: Evaluation + openSUSE-11.3: Rejected by (coolo) + reject date: 2010-02-08 11:13:17 + reject reason: still noone cares. rejecting for real Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Currently the sound card module in YaST hides many options within an "Others" menu button. When adding a sound card the user needs to choose between three configuration ways: automatic, normal and advanced. It is very difficult for the user to choose the appropriate way for him. Ideas for Improvement: * Moving "Volume" and "Start Sequencer" to the "Edit" section. * "Set As Primary Card" is now visible at once to the user * "Play Test Sound" is integrated into the "Edit" section Workflow for "Add" a new sound card: * The user chooses only the vendor and the model. * All the other settings (volume and some advanced settings) can be adjusted via "Edit". * Joystick settings can be done in the "Joystick" module. Mock ups for the redesign are available at: http://en.opensuse.org/Usability/Sound Relations: - feature/id: 304936 Discussion: #2: Guy Lunardi (glunardi) (2008-05-19 00:50:40) mschmidkunz: I believe that re-designing this module is probably a good idea. I hate to mix technology in design and feature discussions but in this case... I wonder if we need to make the module Pulse audio aware. #3: Matthias Eckermann (mge1512) (2008-06-17 17:28:14) (reply to #2) I agree. Just open another FATE regarding Pulse Audio awareness of the YaST module in addition to this one, ...:-) #4: Guy Lunardi (glunardi) (2008-06-18 09:44:48) (reply to #3) Done, I have created 304936 to track the pulse-audio need in YaST. #5: Stephan Kulow (coolo) (2009-04-16 13:37:20) looking for community volunteers #6: Stephan Kulow (coolo) (2009-08-12 10:53:12) (reply to #5) I suggest to reject this for 11.3, it has been around for long enough without any priorities -- openSUSE Feature: https://features.opensuse.org/303460

1 0

[New: openFATE 308956] 2 steps install
by fate_noreply＠suse.de 06 Feb '10

06 Feb '10

Feature added by: Riccardo Pasquini (morphy76) Feature #308956, revision 1 Title: 2 steps install openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Riccardo Pasquini (morphy76) Partner organization: openSUSE.org Description: looking at fate entry #308941 i would like to add another similar behavior: as the software installation completes, i would like to rollback installation (with all dependencies) after a first run of the software or "fix" it if i like that software this chould be a configurable behavior ad installation time default should be turned off a system restart should be considered as a rollback installation another installation should commit the previous pending installation Use Case: 1) install the software 2) try the software 3) commit or rollback entire installation Business case (Partner benefit): openSUSE.org: Everything starts from unused dependencies, happens to try some kind of software to check if it fits yr needs, and if it doesn't, you can easily remove it but not every dependency which comes with it -- openSUSE Feature: https://features.opensuse.org/308956

1 0