- openSUSE Features

[openFate 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 08 Jan '09

08 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #304911, revision 6 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. - openSUSE-11.2: New + openSUSE-11.2: Evaluation SLES-11 Requested by: Ladislav Slezak (lslezak) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304911

1 0

[openFate 304937] Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig
by fate_noreply＠suse.de 08 Jan '09

08 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #304937, revision 6 Title: Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-29 15:43:08 reject reason: This cannot be done in time for openSUSE 11.1. - openSUSE-11.2: New + openSUSE-11.2: Evaluation Requested by: Helmut Schaa (hschaa) Interested: Christian Zoz (zoz) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Interested: Michal Zugec (mzugec) Partner organization: openSUSE.org Description: Yast/sysconfig does already support WPA-EAP wireless connections but is missing support for dynamic WEP connections using 802.1x authentication. wpa_supplicant is able to start such a connection with a network block which uses key_mgmt=IEEE8021X instead of key_mgmt=WPA- EAP. Example: network={ ssid=xxx key_mgmt=IEEE8021X eap=TTLS identity=xxx password=xxx ... } Based on bug #380671 comment #16 and #19. Discussion: #2: Helmut Schaa (hschaa) (2008-07-09 13:34:35) (reply to #1) This request is about dynamic WEP, not static WEP keys (which is already supported). The 802.1x authentication is used to derive dynamic WEP keys repeatedly. It is much more secure then plain static WEP (although not as secure as WPA of course) and still widely used. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304937

1 0

[openFate 304971] Improved Popup support from libyui
by fate_noreply＠suse.de 08 Jan '09

08 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #304971, revision 8 Title: Improved Popup support from libyui openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-16 09:22:38 reject reason: Not needed anymore. - openSUSE-11.2: New + openSUSE-11.2: Evaluation Requested by: Arvin Schnell (aschnell) Interested: Jiri Srain (jsrain) Partner organization: openSUSE.org Description: Currently writing popups with longer texts is difficult: Line wrapping must be done in YCP and thus cannot take font metrics into account. Using RichText widget is also difficult since it's not possible to know the correct height in advance. What I would like to see is a popup that does line wrapping (preserving parapraphs) and adjusts the height of the whole popup accordingly. The popup width should be a parameter or the popup could find a good ratio between width and height. Relations: - missing linebreak in german YaST2 partitioner message (novell/bugzilla/id: 190817) https://bugzilla.novell.com/show_bug.cgi?id=190817 Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-06-27 19:50:50) I guess this is something to leave for our colleagues in engineering to prioritize, thus labeling neutral for PM. #2: Stanislav Visnovsky (visnov) (2008-07-01 13:37:34) (reply to #1) Duncan, this is in your team, up to you if you need this. #3: Arvin Schnell (aschnell) (2008-07-16 10:18:29) Why isn't this needed anymore? What do we have instead? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304971

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #302923, revision 16 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. openSUSE-11.2: Evaluation SLED-11 SLES-11 Requested by: Ján Kupec (jkupec) Interested: Andreas Jaeger (a_jaeger) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. + #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) + I would like to see robust redirection, if possible. The details about + a list, probably should not be in the feature description. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

[openFate 302354] Split metadata by architecture / modules
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #302354, revision 16 Title: Split metadata by architecture / modules Buildservice: New openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-03-28 16:28:18 reject reason: Out of resources. The speed of parsing is greatly improved, downloading is still an issue in 11.0. openSUSE-11.1: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-11-20 19:33:01 reject reason: postponing unless engineering tells me otherwise. - openSUSE-11.2: New + openSUSE-11.2: Evaluation SLED-11-SP1 SLES-11-SP1 Requested by: Stanislav Visnovsky (visnov) Interested: Stanislav Visnovsky (visnov) Partner organization: openSUSE.org Description: All packages are in a single file no matter if they are from different architectures, therefore ZYpp has to download everything Any kind of metadata should be separated by architecture. ZYpp does it for patterns in 10.3, but it is still missing for packages The metadata should be ideally separated by subdirectories and modules. See references on how debian does it References: https://bugzilla.novell.com/show_bug.cgi?id=208452 Relations: - No intel (32bit), 64 bit and ppc catalogs in one repository (inst- source) (novell/bugzilla/id: 309296) https://bugzilla.novell.com/show_bug.cgi?id=309296 Discussion: #1: Duncan Mac-Vicar (dmacvicar) (2007-11-09 16:52:55) This is not true, YaST filter patterns in 10.3. Will edit the feature to represent the real problems #2: Federico Lucifredi (flucifredi) (2008-06-13 20:22:10) Duncan, do we still need this / have an advantage from it ? if so, lets make it Mandatory. #3: Duncan Mac-Vicar (dmacvicar) (2008-06-26 13:17:09) This feature requires: - separate primary.xml files per architecture. 90% effort -> rudi , adrian - tell libzypp to ignore certain pattern or convention ( primary-x86_64. xml ??? ) when downloading -> one liner. It is not much benefit anymore as we are much faster now, but I would recommend pset it to desirable and pass to Rudi and Adrian. #4: Stanislav Visnovsky (visnov) (2008-06-26 13:20:11) (reply to #3) Adrian, this is something for you. #5: Adrian Schröter (adriansuse) (2008-11-06 16:21:18) We have seperate ppc from i586/x86_64 to reduce size. We do not have seperation of meta data yet, but it would not help much anyway, as long as we have no filter on rebuild. All files would change anyway, so the size would be the same. It would actually slow down the process due to multiple downloads. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302354

1 0

[openFate 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #302306, revision 40 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. openSUSE-11.1: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. - openSUSE-11.2: New + openSUSE-11.2: Evaluation Requested by: Martin Schmidkunz (mschmidkunz) Interested: Berthold Gunreben (azouhr) Interested: evamaria fuchs (nefuchs) Interested: J. Daniel Schmidt (jdsn) Interested: Matthias Eckermann (mge1512) Interested: Michael Loeffler (sprudel24) Partner organization: openSUSE.org Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302306

1 0

[openFate 300758] Show orphaned packages
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #300758, revision 35 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. - openSUSE-11.2: New + openSUSE-11.2: Evaluation SLED-11 SLED-11-SP1 SLES-11 SLES-11-SP1 Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

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

07 Jan '09

Feature changed by: Federico Lucifredi <flucifredi(a)novell.com> Feature #120340, revision 39 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf <kkaempf(a)novell.com> reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-08-01 10:25:01 reject reason: Out of time. openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. - openSUSE-11.2: New + openSUSE-11.2: Evaluation SLED-11-SP1 SLES-11 SLES-11-SP1 Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Interested: Ján Kupec (jkupec) Interested: Lukas Ocilka (locilka) Interested: Stephan Binner (beineri) Partner organization: openSUSE.org 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 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=120340

1 0

[openFate 305621] Conversion of kernel disk names to by-id or by-label
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature added by: Klaus Kämpf <kkaempf(a)novell.com> Feature #305621, revision 1, last change by Title: Conversion of kernel disk names to by-id or by-label SLES-11-SP1: New Priority Requester: Important Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: Background Using kernel disk names (e.g. /dev/sdX) is discouraged and should be replaced by mount-by-id or mount-by-label specifiers. This is done by default for fresh installs, so all is fine there. However, older systems which were continuously updated, might still use the old disk device names. Such systems might not boot (resp. update) correctly with newer kernels, let alone correct detection of disk devices. Request Provide a tool which maps kernel-based disk names to by-id (resp. by-label) disk names. Ideally, this tool would automatically convert * /etc/fstab * /boot/grub/menu.lst and others. A simple script-based tool is sufficient The tool must be run before the upgrade in order to correctly detect disk devices. YaST should reference the tool when detecting kernel disk device names during upgrade. References: https://bugzilla.novell.com/show_bug.cgi?id=429019 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305621

1 2

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 07 Jan '09

07 Jan '09

Feature changed by: Rajesh Ganesan <ganesanrajesh(a)gmail.com> Feature #304879, revision 16 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. SLED-11 SLED-11-SP1 Requested by: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) + #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) + Well, an excellent idea and most expected too. But + (http://kde.openoffice.org/) seems struck at March 2006 itself. Any + plans(or chance) of revival? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0