December 2009 - openSUSE Features - openSUSE Mailing Lists

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

10 Dec '09

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

1 0

[openFATE 307496] return to having no default desktop environment
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307496, revision 1 Title: return to having no default desktop environment openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: The recent decision that openSUSE needs a default desktop environment must be reverted. * This decision has lead to frictions between the openSUSE sub-communities of GNOME and KDE users which might ultimately result in a drain of supporters of one of these sub-communities to a different distribution. * A default choice during installation gives the wrong impression that even now openSUSE chiefly supports the defaulted desktop environment while the other one is to be used 'at one's own risk' * This decision has acutely affected openSUSE's position as the only distribution which credibly supports both desktop environment * The gains to be had through a 'default desktop environment' are minor to zero, the potential loss and damage to community caused by it is catastrophic -- openSUSE Feature: https://features.opensuse.org/307496

1 10

[openFATE 307065] Terminate DVD image creation and only provide LiveCDs and Net Installs
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Stephen Kellat (skellat) Feature #307065, revision 1 Title: Terminate DVD image creation and only provide LiveCDs and Net Installs openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Stephen Kellat (skellat) Description: The discussion in openFATE #306967 relates to making KDE the default desktop environment for openSUSE. The question of choice arises there. A work-around to this would be to cease creating DVD images for installation and instead focus on LiveCDs and Net Install discs. Parity across desktop environments would be possible in having separate GNOME and KDE LiveCDs while also promoting Xfce into its own LiveCD instead of its obscurity on the DVD. As for Net Install discs, those are intended for experienced users so the rationale being exhibited in #306967 for catering to the needs of new users would not necessarily apply. Net Install discs could keep an expanded desktop environment choice list. Test Case: User desires GNOME experience in openSUSE and downloads the GNOME LiveCD. The kicker at http://software.opensuse.org would make the choice available to the user. Other users desire a KDE experience, an Xfce experience, or an LXDE experience would also be potentially directed by the kicker. ISO naming conventions would have to be adjusted to take into account the variety of LiveCDs possible. Use Case: Building LiveCDs decreases the amount of bandwidth to be consumed by potential users who would otherwise secure the DVD ISO. SUSEStudio could be tied in so that project leaders who were so minded could offer refreshed respins on their own outside the normal distribution cycle. -- openSUSE Feature: https://features.opensuse.org/307065

1 8

[openFATE 307495] GNOME default
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307495, revision 1 Title: GNOME default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: I propose to make GNOME the default desktop in openSUSE. It has been decided that users are overly challenged by having to decide between the GNOME and KDE desktop environments during the installation procedure. If this is true, such users will be overly challenged by the KDE desktop environment which is now planned to be the default choice. This proposal is meant to solve this problem by changing the default desktop environment for openSUSE to GNOME. These are the reasons why GNOME should be defaulted in openSUSE, not KDE: 1) By default an easy-to-use desktop environment should be installed: The way it is planned now, users who are uncertain about what desktop-environment they want because they are not tech-savvy or who don't know either KDE nor GNOME will end up with KDE because it will be defaulted. This basically means that those users who are most in need of a newbie-friendly desktop will get KDE. This clearly is wrong. KDE is an expert-desktop; it's strength is that its highly configurable. This is not what new and/or non-tech-savvy users want, nor is it what they need. KDE users are usually technically advanced and will know how to click the 'KDE' tickbox, while newbies should get GNOME. 2) Consistency with the NOVELL SUSE LinuxEnterprise Linux releases: Users who have heard about SLED/SLES will expect openSUSE to resemble those enterprise-level distributions. They will feel short-changed if they are presented with the unfamiliar KDE-desktop after an openSUSE install 3) GNOME is the world's standard Linux desktop environment: In order to compete on a global level, we should adopt the world's favored Linux desktop environment. The mainly regionally (Germany/Europe) successful KDE is not the solution for international success but a niche product. All globally successful distributions use GNOME; such as Red Hat Enterprise Linux, Fedora, Debian and most prominently Ubuntu. 4) Ubuntu: We must present a strong alternative to Ubuntu. This can NOT be a KDE desktop as we can see by the relatively low popularity of Kubuntu. KDE can never attract more than a minority of expert users. We must build on the innovations that won SLED awards and popularity. 5) Innovation: To say it outright, KDE had its chance to innovate and failed. KDE 4 was a massive disappointment even to hard-core KDE users in that it produced no enhancement to user-experience nor stability. With the upcoming GNOME 3 release openSUSE has the chance to present revolutionary user experience by the introduction of Gnome-shell as an alternative UI, while still providing more users with the option to continue using the traditional GNOME UI. 6) Attracting developers: What openSUSE already has is an abundance of contributors to KDE. We now urgently need to attract more GNOME developers by focusing on GNOME development and showing commitment to success in our competition with Ubuntu. openSUSE should, of course, also ship and support KDE. So experienced users can choose it. But new users should have GNOME as a default. Please note that I would have preferred if openSUSE had remained with its policy of treating both desktop-environments as equals, but unfortunately, following a request by some KDE-proponents, that policy has been changed to a popularity contest between both DEs by statistics and voting-contests in openFATE. This feature request is nothing but a neccessary reaction to proposal #306967, so that users have a choice to vote for either KDE or GNOME to be defaulted. -- openSUSE Feature: https://features.opensuse.org/307495

1 15

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

10 Dec '09

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

1 0

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

10 Dec '09

Feature changed by: Robert Davies (robopensuse) Feature #120340, revision 125 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. #35: Robert Davies (robopensuse) (2009-12-07 21:21:45) (reply to #34) It is possible to grab the small "odds & sods" together that start being downloaded early in install even if they are logically independant? The trouble I notice on network install, is that there's many small packages not particularly important packages, which don't let the TCP/IP download get to decent speed, making things crawl early on at nowhere near usual bandwidth. So a strategy, like a browser of getting small files in parrallel, whilst mainly wanting those large consistent sets you mention, might make things look pleasingly snappy, rather than naive. Of course if a large package were to be downloaded, as the small ones arrive and are installed noone would complain. + #36: Robert Davies (robopensuse) (2009-12-10 16:21:39) + Testing out Kubuntu 9.10, and one of early things it does on starting + Konqi, is suggest installing "restricted" multia-media codecs. The + downloads were fast, stating off at full 10Mb/s, just tailing off a + touch after a while. Similarly installing 110 bug fix updates took + only a few minutes, despite requiring full kernel download. + By comparison, though zypper itself is fast searching in DB, getting + the repo info and sequence of small files, can really keep the end user + waiting with alot of under-utilised bandwidth. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

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

10 Dec '09

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

1 0

[New: openFATE 308503] Leverage jockey for driver management
by fate_noreply＠suse.de 09 Dec '09

09 Dec '09

Feature added by: Atri Bhattacharya (badshah400) Feature #308503, revision 1 Title: Leverage jockey for driver management openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Atri Bhattacharya (badshah400) Description: Installing non-oss drivers like Nvidia for display and broadcom drivers for wireless in openSUSE is still quite painful. A user has to know he/she has a non-supported chipset and what it is to actualy add the repository from the list of cimmunity-repositories or browse to the required website, for example http://en.opensuse.org/NVIDIA Ubuntu uses a driver management software called jockey that works quite well for them actually. From the website of maintainers [https://launchpad.net/jockey] "Jockey provides an user interface and desktop integration for installation and upgrade of third-party drivers. It is written in a distribution agnostic way, and to be easily portable to different frontends (GNOME, KDE, command line)." We should make use of jockey for driver management in openSUSE 11.3 by default, and leverage the software for our puposes. It will immensely benefit openSUSE usability-wise to have the drivers detected at first boot and have them installed by one-click-install or zypper for example. -- openSUSE Feature: https://features.opensuse.org/308503

1 0

[New: openFATE 308493] GENtle
by fate_noreply＠suse.de 08 Dec '09

08 Dec '09

Feature added by: Jens Staal (staalmannen) Feature #308493, revision 1 Title: GENtle Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Jens Staal (staalmannen) Description: Include in science repositories. GENtle is a DNA cloning tool similar to Vector NTI. http://sourceforge.net/projects/gentle-m/ -- openSUSE Feature: https://features.opensuse.org/308493

1 0

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

07 Dec '09

Feature changed by: Robert Davies (robopensuse) Feature #120340, revision 124 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. + #35: Robert Davies (robopensuse) (2009-12-07 21:21:45) (reply to #34) + It is possible to grab the small "odds & sods" together that start + being downloaded early in install even if they are logically + independant? The trouble I notice on network install, is that there's + many small packages not particularly important packages, which don't + let the TCP/IP download get to decent speed, making things crawl early + on at nowhere near usual bandwidth. + So a strategy, like a browser of getting small files in parrallel, + whilst mainly wanting those large consistent sets you mention, might + make things look pleasingly snappy, rather than naive. Of course if a + large package were to be downloaded, as the small ones arrive and are + installed noone would complain. -- openSUSE Feature: https://features.opensuse.org/120340

1 0