February 2009 - openSUSE Features - openSUSE Mailing Lists

[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