December 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308452] Version-independent Yast Meta Package
by fate_noreply＠suse.de 07 Dec '09

07 Dec '09

Feature added by: Todd R (TheBlackCat) Feature #308452, revision 1 Title: Version-independent Yast Meta Package openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: Currently there has to be a separate yast meta package for every version of every distribution. I think it would be much better for users of the meta package was told what distribution the system is using and automatically selects the correct version, or reports that the software is not available for that particular distribution if need be. It can already do that for the architecture. I know this has backwards-compatibility issues but that will disappear as support for older versions of distributions is dropped (at least for the yast meta package search engines). Currently, for instance, when someone searches for "kernel-default" they get 35 pages of results, while only 4 of those pages are relevant to openSUSE 11.2 users. -- openSUSE Feature: https://features.opensuse.org/308452

1 1

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

07 Dec '09

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

1 0

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

07 Dec '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #120340, revision 123 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: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: 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). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) Absolutely: I agree with you Eduard. The optimized way is to run a download process while rpm -{i,U} is running in the background, as all resources (Disk I/O, CPU, Net) can get used parallel. The only trick is to keep the installation of following packages on hold, if there is some kind of package which takes longer (like kernel-{default,source}; to keep --requires safe; example: kmp's which rely on the specific kernel version to be installed first, however even this could be developed in an optimized way, as package lists and therefore also package requirements are available at time of download). I think there would even be real great customization options possible like an option such as --download-threads. So if the installation/upgrade can keep up with the downloadspeed you will get *significant* performance. And even if not -> it could never get slower. #31: Bart Otten (bartotten) (2009-11-08 13:46:41) (reply to #26) Guess it is too late for for 11.2 but I think Eduard and Michael made a good point. This request is old, even before openFATE was for public... #32: Ján Kupec (jkupec) (2009-11-09 11:25:45) (reply to #26) Well, whether we should do one thing first and then the other, that's debatable, but the point is we do want this downloading while installing . The only issue here are the resources and priorities. Now that we have the first, we can hopefully move on to the next for 11.3 #28: Reza Davoudi (rd1381) (2009-10-27 14:35:07) plz make it so that it be an option in GUI not just command line i am sick of going through cmdline flags and options #29: John Bester (johnbester) (2009-10-29 07:13:05) I think the proposed sulotion will help, but to me this is not the real important issue. The most frustrating issue around installing a small package using YaST is the repository upgrade that must complete before you can do anything. (Unfortunately we do not all have the internet speeds as are the norm in Europe and US). The worst is actually when you have your laptop somewhere where you do not have internet access and have to wait for connection timeouts before you can do an installation. It happened a few times that I just wanted to install a small tool which slipped my mind when I did a clean install (such as midnight commander) quickly so that I can continue with what I am doing. At this point I am not fussed about having the absolute latest security fix - I just need to get going. In any case, I would propose that when you open the package manager, it should kick off a thread to download repository updates into a temp folder. The next time you start the package manader, it can simply replace those repositories for which there are updates available in the temp folder. My reasoning is: If I opened the package manager yesterday and I open it again today (and maybe again later today), why should I always wait a few minutes before I can start selecting packages? Switching off the refresh feature in "Software repostories" is not an option, because it takes too long and you typically do not want it switched off. #30: Reinhard Max (rmax) (2009-10-29 09:59:10) (reply to #29) Please open a new feature request for your proposal, as it is unrelated to the feature that is being discussed here. #33: Fco. Javier Nacher (xiscoj) (2009-12-07 09:39:04) hi, why don't we learn from another package managers?. I usually use smart ( http://labix.org/smart (http://labix.org/smart) ), I think it working mode is the apropiate. It downloads in parallel and after downloading all packages, installs them sequentially, also allows to update channels pressing a button only on demand, so it opens faster. I think that parallel install is not a good choice but parallel download is more than recommended. + #34: Duncan Mac-Vicar (dmacvicar) (2009-12-07 11:01:03) (reply to #33) + You missunderstood the feature. The feature talks about downloading + multiple files at the same time, and installing what is possible to + install at the same time. It does not implies that multiple packages + are installed in parallel (however it does not discard it). + You give no reason when stating that "parallel install is not a good + choice". + Downloading in parallel is something we will do anyways. However, as we + have DownloadInAdvance and DownloadInHeaps, we can download group of + packages that form a minimal dependency transaction. I doubt smart has + this information. This would allow us to download the maximum amount of + packages (either sequential or in paralell) that can be downloaded and + installed while leaving the system in a consistent state. Those could + be installed in parallel while the next "heap" or group is downloaded. + Any error in the next download would leave the system still in a + consistent state. + So yes, we should learn from smart, yum and others, but we should not + just copy, as we don't have all the limitations they do have, and that + means we can actually try to improve things. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

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

07 Dec '09

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

1 0

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

07 Dec '09

Feature changed by: Fco. Javier Nacher (xiscoj) Feature #120340, revision 122 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: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: 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). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) Absolutely: I agree with you Eduard. The optimized way is to run a download process while rpm -{i,U} is running in the background, as all resources (Disk I/O, CPU, Net) can get used parallel. The only trick is to keep the installation of following packages on hold, if there is some kind of package which takes longer (like kernel-{default,source}; to keep --requires safe; example: kmp's which rely on the specific kernel version to be installed first, however even this could be developed in an optimized way, as package lists and therefore also package requirements are available at time of download). I think there would even be real great customization options possible like an option such as --download-threads. So if the installation/upgrade can keep up with the downloadspeed you will get *significant* performance. And even if not -> it could never get slower. #31: Bart Otten (bartotten) (2009-11-08 13:46:41) (reply to #26) Guess it is too late for for 11.2 but I think Eduard and Michael made a good point. This request is old, even before openFATE was for public... #32: Ján Kupec (jkupec) (2009-11-09 11:25:45) (reply to #26) Well, whether we should do one thing first and then the other, that's debatable, but the point is we do want this downloading while installing . The only issue here are the resources and priorities. Now that we have the first, we can hopefully move on to the next for 11.3 #28: Reza Davoudi (rd1381) (2009-10-27 14:35:07) plz make it so that it be an option in GUI not just command line i am sick of going through cmdline flags and options #29: John Bester (johnbester) (2009-10-29 07:13:05) I think the proposed sulotion will help, but to me this is not the real important issue. The most frustrating issue around installing a small package using YaST is the repository upgrade that must complete before you can do anything. (Unfortunately we do not all have the internet speeds as are the norm in Europe and US). The worst is actually when you have your laptop somewhere where you do not have internet access and have to wait for connection timeouts before you can do an installation. It happened a few times that I just wanted to install a small tool which slipped my mind when I did a clean install (such as midnight commander) quickly so that I can continue with what I am doing. At this point I am not fussed about having the absolute latest security fix - I just need to get going. In any case, I would propose that when you open the package manager, it should kick off a thread to download repository updates into a temp folder. The next time you start the package manader, it can simply replace those repositories for which there are updates available in the temp folder. My reasoning is: If I opened the package manager yesterday and I open it again today (and maybe again later today), why should I always wait a few minutes before I can start selecting packages? Switching off the refresh feature in "Software repostories" is not an option, because it takes too long and you typically do not want it switched off. #30: Reinhard Max (rmax) (2009-10-29 09:59:10) (reply to #29) Please open a new feature request for your proposal, as it is unrelated to the feature that is being discussed here. + #33: Fco. Javier Nacher (xiscoj) (2009-12-07 09:39:04) + hi, + why don't we learn from another package managers?. I usually use smart + ( http://labix.org/smart (http://labix.org/smart) ), I think it working + mode is the apropiate. It downloads in parallel and after downloading + all packages, installs them sequentially, also allows to update + channels pressing a button only on demand, so it opens faster. + I think that parallel install is not a good choice but parallel + download is more than recommended. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 07 Dec '09

07 Dec '09

Feature changed by: Martin Schmidkunz (mschmidkunz) Feature #303873, revision 19 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 17:47:05 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) #5: Robert Davies (robopensuse) (2009-11-30 17:48:32) Recent installs of oS (11.[12] feature few license agreements, surely user pays price for an addiction to proprietary software if they get very many. There would seem to be other areas in YaST UI which would give majority more benefit than a rarely used license overview of type shown (though it looks nice). A way package installation history springs to mind. #6: Robert Davies (robopensuse) (2009-12-02 19:29:22) (reply to #5) Did one today, no popups for licenses (just Novell) on initial install, 2 pop ups on first update, for Adobe Flashplayer and MS web fonts. Not exactly onerous. + #7: Martin Schmidkunz (mschmidkunz) (2009-12-07 08:58:17) + A further UI simplification would be: + ----------------------------------- + License Terms + [ ] I accept the license terms for product A [Show License Terms] + [ ] I accept the license terms for product B [Show License Terms] + [ ] I accept the license terms for product C [Show License Terms] + [Back] [Cancel] [Next] + ----------------------------------- + The user could see the license terms when he clicks on the [Show + License Terms] + button (as a pop up). -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 307736] Evaluate ABRT and use it instead of Apport
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature changed by: Jakub Rusinek (liviopl) Feature #307736, revision 4 Title: Evaluate ABRT and use it instead of Apport openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: ABRT project seems to do the same thing as Apport, but seems better designed and thus is much more extensible. This allows to report crashes also from non C/C++ programs (e.g. Python), report to bugzilla/trac, upload crashes to FTP and so on. More info: * https://fedorahosted.org/abrt/wiki * http://fedoraproject.org/wiki/Features/ABRT + Discussion: + #1: Jakub Rusinek (liviopl) (2009-12-06 23:07:26) + ABRT catches Firefox crashes and automatically reports it. That's + great. Especially, when you take a look and notice, that downstream + Firefox doesn't usually report them and for this you need to use + upstream one (which contains Mozilla Crash Reporter). + I didn't see Apport anytime in action. Does it work at all? -- openSUSE Feature: https://features.opensuse.org/307736

1 0

[New: openFATE 308482] Replacement for Atlantik
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: Thomas Kamps (progger1986) Feature #308482, revision 1 Title: Replacement for Atlantik Package Wishlist: Unconfirmed Priority Requester: Neutral Requested by: Thomas Kamps (progger1986) Description: I have build a Qt4 based replacement for Atlantik from KDE3 and i'd like to see it in the standart repo. Look at http://qt-apps.org/content/show.php/Capitalism?content=113173 for more information. -- openSUSE Feature: https://features.opensuse.org/308482

1 0

[New: openFATE 308481] Automatically de-select UTC when installing in a virtual machine
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: Bernhard Walle (bwalle) Feature #308481, revision 1 Title: Automatically de-select UTC when installing in a virtual machine openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Bernhard Walle (bwalle) Description: The emulated hardware clock in virtual machines (VirtualBox, VMWare, QEmu/KVM ...) runs at local time in most cases. At least for VirtualBox it's not configurable. When installing openSUSE in VirtualBox, the check button "run system clock at UTC" is automatically checked. Since in most cases I can imagine that's wrong -- why not detect the installation inside a VM (with dmidecode string) and automatically not check that button? -- openSUSE Feature: https://features.opensuse.org/308481

1 0

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

06 Dec '09

Feature changed by: Frank Vanderham (twelveeighty) Feature #305296, revision 123 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Done Priority Requester: Important Projectmanager: 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 Test Case: * Log in to GNME/KDE * call beagle-status and check if beagle does not run. * Start searching in GNOME/KDE and check that the application ask you to start beagle. * After that run beagle-status again to check that beagle runs. 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) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #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? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #55: Cameron Blackwood (drkorg) (2009-10-05 03:50:38) (reply to #25) Id prefer to not have it installed, but disabled by default comes a close second. ;-) #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) you are luky then.. beagle on my pc make them very very slower, it should be disabled by default, if you need it, then you insta/activate it #34: Marc collin (collinm) (2009-07-04 15:03:05) Disable it by default, i use kde... and there is alreay a solution for it.... we could also disable mono... #35: Michael Löffler (michl19) (2009-07-07 11:29:54) Vincent, can you do this? As it is our highest rated feature it would be very good to have implemented rather soon then later. Thanks. #36: Vincent Untz (vuntz) (2009-07-07 12:09:24) Well, it depends on what is the decision here: * if it's something that should be done during installation, I have no idea how to implement that. * If it's just disabling beagle by default, I'll need to investigate, but it hopefully only is changing something in a .desktop file. So what's the process on taking a decision here? That being said, just disabling beagle by default might expose a usability issue: if it's disabled, it will not index files. So when the user searches for something for the first time, it will not work and users won't understand it, and will just give up on it. (It might be solvable with a nice message the first time the user does a search, though) #37: Michael Löffler (michl19) (2009-07-07 14:43:12) (reply to #36) Vincent, please see #1. What you describe is exactly what Federico suggested as well. So I'd say disable beagle by default and offer option to run at first search. #38: Karl Eichwalder (keichwa) (2009-07-07 15:08:23) (reply to #37) IIRC, the kde help center works this way and it is rather annoying. Most of the time, the desktop computer idles... I think on the Mac the desktop search (spotlight) is enabled by default. #39: Stephan Kulow (coolo) (2009-07-07 15:16:24) (reply to #38) you're wrong. Most of the time, the desktop computer saves power. #40: Karl Eichwalder (keichwa) (2009-07-07 15:36:52) (reply to #39) Yes, you are right. Once the work is done. On my desktop at work, beagled and beagled-helper do not cause any notable load. It's different on my test machine, though. #41: Dean Hilkewich (deanjo13) (2009-07-07 16:36:55) (reply to #38) When it comes to indexing services spotlight is far ahead of beagle in usability and performance. It is also easily disabled with a system setting if desired. Even on old G4's spotlight doesn't kill performance like beagle does. #42: Segundo Luis Martín Díaz Sotomayor (zchronos) (2009-07-07 17:47: 18) Beagle should be disabled by default. #49: Vincent Untz (vuntz) (2009-07-18 18:42:21) Fixed in GNOME:Factory, and submitted to openSUSE:Factory (#14802). #51: Hecke Degering (hecke_goe) (2009-08-10 09:02:11) just heard about this request... i would like to strongly support it. Beagle eats way too much ressources away for something to be convenient. btw: in our institutes desktop configuration (OpenSuse, ~60machines) we got rid of beagle totally. Unfortunately some packages depend on beagle- lib, so there is some leftover in the package selection, but this should not harm, hopefully;-) #52: Richard Lennox (rlx01) (2009-08-13 15:57:12) I agree. It just gets in the way. Disable it by default. #60: Didencool Andrey (didencool) (2009-11-21 07:51:59) agree, it should be disabled by default. + #61: Frank Vanderham (twelveeighty) (2009-12-06 17:49:01) + Windows' most annoying aspect: doing things you never told it to do, or + are even aware of, slowing you down when you decide to use "your" + computer. + openSUSE most annoying aspect: ditto for Beagle and that annoying "man" + pages indexing. + Kill the dog. -- openSUSE Feature: https://features.opensuse.org/305296

1 0