February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #305598, revision 7 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) I don't think so. You have to go actively into Yast and search there. My request is to bring this closer to the user - possibly a simple search bar in the application browser. So...a simple example might be (based on recent real user experience): - User needs a VPN app - User goes into Application Browser, types in VPN in the Filter - No VPN tool is available, no suggestions or next steps are offered. - User abandons search and concludes there is no VPN app installed on the system An ambitious - and more Linux savy - user might start searching elsewhere or try command line (or open Yast). The scenario I recommend is: - User types in "VPN" in the application browser filter - System returns an answer: "You don't currently have a VPN client linked to the application browser, but there is a VPN client on your system. Click here - BUTTON - to add a shortcut for this application in your application browser. - User accepts and from now on has the - already available - VPN client at his/her fingertips. There might be something in openSUSE - I only use SLED - that could address this + #5: Martin Schmidkunz (mschmidkunz) (2009-02-19 16:04:13) + What about using (and therefore promoting :-)) the one-click- + installation-icon used by software installation via openSUSE.org? I + played a little bit around with that idea: + http://en.opensuse.org/Image:Application_browser_1click.png Of course + we should check the readability of this idea :-) -- openSUSE Feature: https://features.opensuse.org/305598

1 0

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

19 Feb '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 37 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. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. + #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) + I agree with everything you said, but you must realize I/we aren't + arguing against search. We're arguing against beagle. + I personally use google desktop search on a daily basis. And it works + well. I assume that it does all its work when I'm not physically using + the computer (a policy that is ideal for desktop usage). I'm not + advocating its inclusion (primarily license reasons and kde integration + reasons) but you should see that I'm not against a search or anything + like that. + Beagle on the other hand, I've tried to give it a fair shot a few + times. To see if it has improved (something I will admit Banshee has + done). But its *always* problematic. Something that is echoed daily on + IRC and the mailing lists. The firefox extension causes huge amounts + errors and slow downs. The actual search program maxs out the CPU. IO + brings the computer to a crawl when I need to get work done etc. It's + just not pretty. + So if Beagle works well, I'd love to use it. But it doesn't and + shouldn't be included. Put it this way. I would really like to see + kernel initialization of graphics devices. However, until it's finished + and works properly -- I think we'd both agree that it shouldn't be on + our systems. I know it's not a good test for everything, but have you + noticed how many other desktop distros have chosen to include beagle? -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 19 Feb '09

19 Feb '09

Feature changed by: Pavol Rusnak (prusnak) Feature #305656, revision 5 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. Discussion: #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) Also package name can go directly to package in source project... I would like that too. Nice idea. #2: Sascha Manns (saigkill) (2009-02-18 18:34:49) That sounds good. I'm vote up +1 + #3: Pavol Rusnak (prusnak) (2009-02-19 12:45:44) + I already reported it two months ago in bugzilla: + http://bugzilla.novell.com/show_bug.cgi?id=461306 -- openSUSE Feature: https://features.opensuse.org/305656

1 0

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

19 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 36 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. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. + #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to + #14) + Ok, I hope that my comment did not sound as gruff or ... brusque, for I, + basically, hoped to present a different opinion. What I did not intend + was to, evidently, irritate somebody by not completely assenting to his + opinion. + See: I am working for a university in Germany. We have 45.000 students + and a staff of employees of a size appropriate for this amount of + students. We rely heavily on the capabilities of a search system (to be + honest: in this case not beagle, but somethings similar to beagle). I + am one person who posts here but, to stay in your line of + argumentation, statistically I represent so many single individuals, + that my vote could be multiplied by a "pretty fight factor". Now the + problem is that most of these people just use a search feature but do + not understand of configure it. But they will notice when it is gone . + These users do not vote, they are not involved in community work, they + are not programmers, not system architects, not members of an online + community. But they use systems like beagle. I know, as I stated in my + first post, some people, which I got to switch their OS, from Windows + to openSUSE. These people will miss features, too. Especially if you + are so eager so simple remove this feature despite the fact that it was + part of the distribution for many years. + The more I write here, the angrier I get. I mentioned that Lucifredi + and Kulow are of another opinion (disable but no remove the software; + make it possible to switch it on or off when needed), an opinion I + agree with. Is it possible that YOU ignored that part? This is quite + normale for the usual open source community. To me it is a relatively + illusive concept, the more I deal with it (and I deal with it for now 9 + years) the more I learn about the ignorance it contains. Too many + people choose rather to ignore those who have to vote (usually called + users) and instead see their opinion as the ultimate measure to decide + pro and contra. Did it come to your mind that about 80-90% of those who + start to create an account for a portal like openFATE, who pay the time + to write some comments and skip through all these proposals in this + portal, that 80-90% of these people might perhaps be programmers? Geeks + and nerds as they are called nowadays. This is no real statistic + representing the opinion of those who use a software, it is a statistic + of those how develop a software. Make this clear to you. + So to get back on a rather rational level: I recognize that you are of + another opinion. That most of the people here are. But, and that was + important to me, these votes in here are not a real representation of + opinions. I prefer openSUSE after all these years espcially because it + was bought by Novell. Because they do research in usability, which is + the only real way to ask the customers/the users, how to design the + software. That is why I said, that an easy startup QA for the normal + user is the best to do. Do not be too ignorant. The users know what + they want, even if they miss some technical versatily, they will still + take note of features that are missing, of bugs in the browser, of + missing parts in the system "that they know worked on a different OS" + or whatever else. Perhaps they annot name the source of the problem and + do not know if it is a real design issue or a real bug. But they will + say that the feature is not how they expected it to be. + I recently said to a colleague of mine that the times of Mac OS are + nearly over. The only real advantage they have is that they can design + an OS without paying too much attention to different hardware. They + know exactly which hardware their OS will possible have to run on. If + Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the + box on ANY posible hardware, with all features running without a + problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) + it would be undeniable that Linux will be the winner. I see progress + made well into that direction. I see that Linux is close to this goal, + to solve these issues in nears time (most Graphic Cards now easily + work, with only a few exceptions). So please do not disappoint me. I + have to lead discussions about Linux/Windows and Linux/MacOSX nearly + every week. I do not want to have them led in vain. Look at what Mac + and Windows do, they have a search system with an index. Make ours + betters, faster and less memory hungry instead of removing it. These + who switch from Windows/Mac to Linux (for instance to openSUSE) want to + find new and more useful features instead of fewer features. + I know this post was too long. I am sorry, but it thought it + necessary. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 18 Feb '09

18 Feb '09

Feature changed by: Sascha Manns (saigkill) Feature #305656, revision 4 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. Discussion: #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) Also package name can go directly to package in source project... I would like that too. Nice idea. + #2: Sascha Manns (saigkill) (2009-02-18 18:34:49) + That sounds good. I'm vote up +1 -- openSUSE Feature: https://features.opensuse.org/305656

1 0

[openFATE 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 18 Feb '09

18 Feb '09

Feature changed by: Marek Stopka (m4r3k) Feature #305656, revision 3 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. + Discussion: + #1: Marek Stopka (m4r3k) (2009-02-18 18:07:01) + Also package name can go directly to package in source project... I + would like that too. Nice idea. -- openSUSE Feature: https://features.opensuse.org/305656

1 0

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

18 Feb '09

Feature changed by: Eric Springer (Erikina) Feature #305296, revision 34 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. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. + #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) + Yes, a search is very useful. Yes, some people find beagle beneficial + (as apparently you do). But the vast majority (Currently the vote is at + 47:1) of people it doesn't work well with. And that's truly an amazing + statistic, as it's super easy to see and use the feature it provides + but much harder to see that it's beagle causing so many (resource + related) problems. + And if that statistic alone isn't enough to convince you it's not a + sensible default, then I have absolutely no idea how to. There really + should be a resemblance of QA in place, especially for default (and + completely optional) packages. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305598] Improve access to non-preinstalled apps
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Richard Doll (richard_doll) Feature #305598, revision 6 Title: Improve access to non-preinstalled apps openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Richard Doll (richard_doll) Partner organization: openSUSE.org Description: Currently, we include many apps in the distribution which are by default not installed although accessible for installation via Yast (eg. VPN) Users should have an easy way to find out which apps are available on the system and simply need to be installed. This could be an extension to the application browser (eg. "Search catalog for non-installed applications") or other means to make users aware. Business case (Partner benefit): openSUSE.org: We include numerous "un-advertized" applications in the distribution - it seems self-evident that we should make users aware of what is available to them. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:20:33) This is a bit similar to the issue with YaST, where we made the decision to always install all modules to provide the overview of our capabilities. I am obviously not suggesting this route here, but some of the alternative solutions to the YaST issue may be applicable here. #2: Gerald Pfeifer (geraldpfeifer) (2009-01-02 12:21:26) Guy, Michl, something for our desktop / UI teams to look into? #3: Michael Loeffler (sprudel24) (2009-01-09 18:34:08) Hmm, doesn't the Software Management module in YaST provide exactly this? + #4: Richard Doll (richard_doll) (2009-02-17 10:29:18) (reply to #3) + I don't think so. You have to go actively into Yast and search there. + My request is to bring this closer to the user - possibly a simple + search bar in the application browser. + So...a simple example might be (based on recent real user experience): + - User needs a VPN app - User goes into Application Browser, types in + VPN in the Filter - No VPN tool is available, no suggestions or next + steps are offered. - User abandons search and concludes there is no VPN + app installed on the system + An ambitious - and more Linux savy - user might start searching + elsewhere or try command line (or open Yast). + The scenario I recommend is: - User types in "VPN" in the application + browser filter - System returns an answer: "You don't currently have a + VPN client linked to the application browser, but there is a VPN client + on your system. Click here - BUTTON - to add a shortcut for this + application in your application browser. - User accepts and from now on + has the - already available - VPN client at his/her fingertips. + There might be something in openSUSE - I only use SLED - that could + address this -- openSUSE Feature: https://features.opensuse.org/305598

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Andreas Gruenbacher (agruen) Feature #305561, revision 7 Title: Install Debuginfo Package by build-id openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Jan Blunck (janblunck) Developer: Jan Blunck (jblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 Discussion: #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) Not sure why agruen is set as engmgr, this is simply some rpm hackery. Put a debuginfo.prov script in place, that checks the file list given and give it all /usr/lib/debug/.build-id files. And it will transform /usr/lib/debug/.build- id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo (d9cff1044033b4781ab47388b422b07cb72708). After that you can use zypper install -C "debuginfo (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo installed (11.1-x86_64 example). This is an effort of half an hour without testing. + #2: Andreas Gruenbacher (agruen) (2009-02-17 16:15:18) (reply to #1) + This should work, and the debug info repository metadata should still + remain reasonably small. -- openSUSE Feature: https://features.opensuse.org/305561

1 0

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

17 Feb '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305296, revision 32 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. + #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) + Despite all who now have voted for this proposal, I just have to vote + against it. At least in the forms discussed here. I use Beagle heavily + as do some other people I got convinced to use openSUSE instead of + Windows. A good Desktop search was among the arguments to move these + people to change their OS (others arguments were Deskbar etc... which + btw. does not necessarily need Beagle but gets some interesting + advantages IF Beagle is activated). Why not simply ask at startup how + to configure some basic system defaults. Among them there could be + beagle. So concerning the proposals of Federico Lucifredi, Stephan + Kulow and so on, I am definitively of the same mind. Beagle should be + installed by default, but it should be easy to switch it "on" or "off" + whenever one wants. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 301207] Support encrypted partitions in mediamanager
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #301207, revision 37 Title: Support encrypted partitions in mediamanager openSUSE-10.2: Rejected by Stephan Kulow (coolo) reject date: 2006-10-25 12:10:25 reject reason: no time left Priority Requester: Important Projectmanager: Important openSUSE-10.3: Rejected by Jared Allen (jpallen) reject date: 2007-08-13 19:01:49 reject reason: Didn't make it. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Dirk Mueller (dirkmueller) reject date: 2008-04-11 16:44:11 reject reason: out of time due to KDE4 switch Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-16 15:48:12 reject reason: The common encrypted partition cases are handled already and there is a lack of time before feature freeze. Priority Requester: Important Projectmanager: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-02-17 11:38:03 + reject reason: there are more important features missing in KDE4. Priority Requester: Important Requested by: Stephan Kulow (coolo) Description: KDE's mediamanager currently only supports volumes from HAL, which excludes encrypted partitions only listed in fstab. This needs integrated support including new strings to indicate it's encrypted. Discussion: #1: Stephan Kulow (coolo) (2007-11-16 11:40:04) encrypted partitions become more and more popular, so we should get forward here. We support encryption for removable media now thanks to Daniel's work, but partitions are still out from media:/ #2: Dirk Mueller (dirkmueller) (2008-03-25 11:28:48) there is a improved solution for KDE3 thanks to Tom Patzig. This needs forward port to KDE4 however for 11.0, which will be a non-trivial amount of work. I would say it is 2-3 weeks to get it done properly, including learning solid. #3: Dirk Mueller (dirkmueller) (2008-04-11 16:43:37) the time is not available, beta1 is imminent and there are too many other things to fix. #4: Guy Lunardi (glunardi) (2008-06-03 22:34:50) (reply to #3) Should this be re-prioritize for openSUSE 11.1? Sounds like an important feature. #7: Dirk Mueller (dirkmueller) (2008-06-13 15:06:01) (reply to #4) I'm not sure.. the typical use case of encrypted non-hotpluggable media is to have an encrypted home partition, and you have to mount that on boot, otherwise you can't login. I don't know what the use case or the customer value for this feature is. #9: Daniel Gollub (dgollub) (2008-06-13 15:42:54) (reply to #7) This is already implemented: # cryptconfig make-ehd luks image per user in /home/ + pam_mount #10: Dirk Mueller (dirkmueller) (2008-06-13 15:58:52) (reply to #9) yep, I guess this feature is however about other custom mounts, that shouldn't be mounted via pam_mount (??) #5: JP Rosevear (jproseve) (2008-06-13 08:18:02) Dirk, whats the upstream status of this now? #6: Dirk Mueller (dirkmueller) (2008-06-13 15:01:56) KDE4 (upstream and openSUSE) supports encryted hotpluggable media (usb sticks etc) just fine, but this particular feature, the manually to /etc/fstab added feature is not there afaik. #8: Dirk Mueller (dirkmueller) (2008-06-13 15:09:54) (reply to #6) I'll have to check if my understanding is correct, hence still needinfo #11: Dirk Mueller (dirkmueller) (2008-06-23 10:44:56) (reply to #8) support for fstab-only is not upstream #12: Andreas Jaeger (a_jaeger) (2008-07-07 13:03:21) (reply to #11) OK, so let's evaluate what needs to be done for this - and whether we should move it to 11.2. -- openSUSE Feature: https://features.opensuse.org/301207

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305561, revision 4 Title: Install Debuginfo Package by build-id - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory + Projectmanager: Important Requested by: Jan Blunck (janblunck) + Developer: Jan Blunck (jblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 + Discussion: + #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) + Not sure why agruen is set as engmgr, this is simply some rpm hackery. + Put a debuginfo.prov script in place, that checks the file list given + and give it all /usr/lib/debug/.build-id files. + And it will transform /usr/lib/debug/.build- + id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo + (d9cff1044033b4781ab47388b422b07cb72708). + After that you can use zypper install -C "debuginfo + (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo + installed (11.1-x86_64 example). + This is an effort of half an hour without testing. -- openSUSE Feature: https://features.opensuse.org/305561

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 17 Feb '09

17 Feb '09

Feature changed by: Jiri Srain (jsrain) Feature #120340, revision 69 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? + #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) + This is how it works for quite some time. Repositories providing + patches also provide the packages so that they can be installed + directly from the update repositories (provided they contain newer + version). -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 16 Feb '09

16 Feb '09

Feature changed by: Chris Hills (chaz6) Feature #120340, revision 66 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 + #14: Chris Hills (chaz6) (2009-02-16 16:42:06) + Is there a feature request to install using both the base and updates + repo so that the latest packages available at install-time are used, + thus saving bandwidth? -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 16 Feb '09

16 Feb '09

Feature changed by: Jiri Srain (jsrain) Feature #305268, revision 5 Title: Refactor bootloader UI - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[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