February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 16 Feb '09

16 Feb '09

Feature changed by: Bart Otten (BartOtten) Feature #305296, revision 31 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. + #12: Bart Otten (bartotten) (2009-02-16 01:13:58) + I agree with the people voting to disable it by default. I think we + have to keep focus on the 'consumer' and most of them won't use + Kerry/Beagle. + ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 15 Feb '09

15 Feb '09

Feature changed by: Jean-Daniel Dodin (jdd) Feature #305326, revision 11 Title: 5 Second Boot openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-02-09 15:47:52 reject reason: Sorry to be harsh, but this feature can't be implemented as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. + #3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27) + may be this is plain stupid, forgive me if it is. The install time was + dramatically reduced by the use of "images" of installs. Could it not + be possible to build "images" of the installed system - that is to have + all the necessary files on boot able to read at once. It's not exactly + the same as suspend to disk, of like a suspend to disk with only the + system. + Most computers never change hardware and a new grub entry could be + added: boot with new hardware -- openSUSE Feature: https://features.opensuse.org/305326

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 15 Feb '09

15 Feb '09

Feature changed by: Jean-Daniel Dodin (jdd) Feature #305296, revision 30 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree + #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) + +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 11 Feb '09

11 Feb '09

Feature changed by: Johnny Stovall (oouc) Feature #305296, revision 28 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. + #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) + Beagle should be disabled by default. Everyone in the DFW Linux Users + Group complained when Suse added it. It causes nothing but trouble for + me. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 11 Feb '09

11 Feb '09

Feature changed by: Manuel Bejarano (mbejaranoc) Feature #305296, revision 26 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. + #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) + 100% agree #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 10 Feb '09

10 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #302159, revision 28 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). - #9: Stanislav Visnovsky (visnov) (2007-11-23 11:26:19) (reply to #7) - The feedback on the mailing list clearly shows users are asking for - this a lot. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 10 Feb '09

10 Feb '09

Feature changed by: Pavol Rusnak (prusnak) Feature #305641, revision 11 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Additional notes: The plan is to _INSTALL_ the Puppet infrastructure by default. No default-running is planned - I thought it was important to clarify this. Addtionally, Facter needs to be packaged and supportable alongside Puppet. Cft should be packaged, but not default installed, and not the target of this focused infrastructure work in this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. + #3: Pavol Rusnak (prusnak) (2009-02-10 15:45:06) + I think anicka did some experiments with puppet. -- openSUSE Feature: https://features.opensuse.org/305641

1 0

[openFATE 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 10 Feb '09

10 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305641, revision 10 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Additional notes: The plan is to _INSTALL_ the Puppet infrastructure by default. No default-running is planned - I thought it was important to clarify this. Addtionally, Facter needs to be packaged and supportable alongside Puppet. Cft should be packaged, but not default installed, and not the target of this focused infrastructure work in this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. -- openSUSE Feature: https://features.opensuse.org/305641

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 10 Feb '09

10 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305296, revision 24 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. + #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) + I wholehearty agree. Having specific applications in the installer is + definitely something that we shouldn't do. Have it disabled by default + and make it easy to enable. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 10 Feb '09

10 Feb '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305634, revision 66 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. + Relations: + - Wiki page for implementation (url: + http://en.opensuse.org/Upgrade/11.2) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0