November 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308335] Net-Installation over WLAN
by fate_noreply＠suse.de 14 Nov '09

14 Nov '09

Feature added by: Sebastian Siebert (Freespacer) Feature #308335, revision 1 Title: Net-Installation over WLAN openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Sebastian Siebert (freespacer) Description: The installation of openSUSE over WLAN should be possible for netbook users. (Other purpose are welcome). It is also called Net-Installation over WLAN (Kernel-Modules of WLAN-devices should be available on board). We need a preinstallation image on based the graphical YAST installation. The Wi-Fi access and encryption data should be typed before starting the installation (Before the YAST installation image will be downloaded). After typing access data, YAST installation configure the WLAN-device (auto-detection) and try to connect to the Router/AP. If the connection will not be established, YAST Installation goes back again to the WLAN configuration for typing the access and encryption data. If the connection is successful, the YAST installation image will be downloaded and then starts the actual Yast installation. This feature should be better integrated as part of the openSUSE 11.3 net-installation. -- openSUSE Feature: https://features.opensuse.org/308335

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 11 Nov '09

11 Nov '09

Feature changed by: Wang Lance (lzwang) Feature #305657, revision 55 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup Discussion: #1: Matthias Nagorni (mnagorni) (2009-08-21 14:26:22) If this can be done with little effort I would be even tempted to rate it Mandatory. #2: Stefan Behlert (sbehlert) (2009-08-25 16:37:57) Alex, is there soemone on your team who could look at that? MAybe with some support form Tambet? #3: Li Bin (binli) (2009-08-26 05:58:01) I and lance wang would like to take care of it. We still don't know the requirement clearly. 1. disallow workers on centrally administered machines to configure different network settings The workers mean the users in administered machines? Does it right that when workers configure network settings it prompt they are no permission? If so I thought we could change the PolicyKit's configuration file to complete it. 2. protect home users that only ever connect to a few well known nets from accidently changing their setup How to distinguish home users from workers? Does it mean don't allow the user to configure the other users connections? #4: Ludwig Nussel (lnussel) (2009-08-26 08:40:53) (reply to #3) Currently there's only org.freedesktop.network-manager-settings.system. modify, introduce something like org.freedesktop.network-manager- settings.user.modify so NM can determine whether it should accept user settings. #16: Wang Lance (lzwang) (2009-09-25 11:26:20) (reply to #4) Hi Ludwig Nussel I have added the following policy action: org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.mobile.apply org.freedesktop.network-manager-settings.user.vpn.apply org.freedesktop.network-manager-settings.user.dsl.apply . NM now can determine whether it should apply the user settings to devices by type. Does the implementation meet your request? I need your feedback to determine what should to do next step. Thanks, Lance Wang #17: Ludwig Nussel (lnussel) (2009-09-25 11:58:50) (reply to #16) Sure, that's even more than I had wished for. Would it be possible to also have a separate privilege for the connection sharing thingy? In contrast to the other configurations that one also messes with iptables and starts a DHCP daemon. #5: JP Rosevear (jproseve) (2009-08-26 17:06:51) (reply to #3) My suggestion would be to look at something like the following: org. freedesktop.network-manager-settings.system.modify org.freedesktop. network-manager-settings.system.add org.freedesktop.network-manager- settings.system.delete and the same for .user - you may even want to specifically allow or disallow adding for specific network types like wired, wireless, etc. You probably also want to have the ability to enable/disable wireless in general and enable/disable networking covered. You can default all of these to the current settings, but adding these would allow more lockdown opportunities. #6: Li Bin (binli) (2009-08-31 11:22:12) Well, We'll works on this feature in this week, know about the PolicyKit and NetworkManager, write the patch if time is okay. Tambet, Do you have any idea about this feature? #7: Luis Medinas (lmedinas) (2009-08-31 18:40:51) (reply to #6) Might worth looking at NM 0.8 (git master), it supports the latest polkit-1 and it should be released before 11.2. Maybe some of this features were introduced. #8: Tambet Ingo (tambet) (2009-09-01 09:40:05) (reply to #7) NM 0.8 will not be out before 11.2, it'll be out for the next Fedora release which will happen after 11.2. Also, current git master does not have any work for this feature, it's just been converted to use the newer, incompatible polkit API. #9: Tambet Ingo (tambet) (2009-09-01 09:43:56) (reply to #6) The upstream has been planning on having similar feature for a while now, but no work has been done on it yet. I strongly suggest to have a discussion with the upstream maintainer before any work gets done, otherwise our effort might end up thrown away as soon as upstream implements it. #10: Li Bin (binli) (2009-09-01 09:14:24) Yes, I talk with the upstream today, just wait for response. You can follow it from below link. Thanks! http://mail.gnome.org/archives/networkmanager-list/2009-September/date.html #11: Stephan Kulow (coolo) (2009-09-07 13:39:17) (reply to #10) didn't see a lot of replies. #12: Li Bin (binli) (2009-09-10 05:24:05) The upstream maintainer Dan already reply this issue, and it's no user case for seperating add, modify and delete permission, and the others was agreed. Lanc wang with me work the sled11 and upstream now, we'll provide a patch in this week. #13: Wang Lance (lzwang) (2009-09-15 08:10:43) Hi I add five policy like the following : org.freedesktop.network-manager- settings.system.wired.modify org.freedesktop.network-manager-settings. system.wireless.modify org.freedesktop.network-manager-settings.system. mobile.modify org.freedesktop.network-manager-settings.system.vpn. modify org.freedesktop.network-manager-settings.system.dsl.modify. As you know there will be one policy one type. I make a patch which works. But I feel a little confused on the user settings. As the user settings are saved in the gconf, so adding someting like manager- settings.user.*.modify make no sense. As far as I know user can always edit their gconf settings. I think what should be done may be the policy that determine if the users can apply their settings to the system devices throught dbus. Given we do it like that, should the nm-applet display the user setting in the menu, when a normal user can not apply his or her settings to system devices? I think it is better that nm-applet show both system settings and user settings, and it will show error dialog if a user try to apply user settings when the user does not have the right do that. Hi Tambet, what do you think? #14: Li Bin (binli) (2009-09-17 11:18:37) (reply to #13) Tambet reply in the mailinglist, we just lock the /system/networking path in gconf and the settings can't be changed. #15: Michael Meeks (michael_meeks) (2009-09-23 16:55:40) We should also add the case mentioned in bug #522742 - to allow disabling the "Create new wireless network" functionality. This is of particular concern to the security team, and I'd like to see it addressed as part of the same work if possible. Otherwise, this looks great - thanks Li Bin :-) #18: Li Bin (binli) (2009-09-25 12:03:28) (reply to #15) Michael, I've viewed the bug#522742, it talk more about sharing, and we don't need to disable "Create new wireless network", user can add it, but when they wanna to apply it by click the connection, check org. freedesktop.network-manager-settings.user.wireless.apply permission like the Lance describe in #16. Does it okay? #19: Michael Meeks (michael_meeks) (2009-09-28 10:10:26) (reply to #18) No - connecting to a new wireless network is -very- different from sharing all your existing connections over your current wireless network; I can see why people would want to allow one and not allow the other. We should (ideally) have a different policy setting for this - if possible. Thanks #25: Wang Lance (lzwang) (2009-10-28 11:49:58) (reply to #15) Hi Michael I have read bnc #522742. And it is about sharing network. I wonder that why only the "Create new wireless network" need a policy, since all kinds type connection can be shared. As far as I know in nm-applet 7.0 the "Create new wireless network" is only for adhoc wireless connection. Did you mean that sharing adhoc wireless connection have security problem? And other type connections do not ? Thanks, Lance Wang. #20: Tanja Roth (ta-ro) (2009-10-05 15:01:26) Can you please confirm what the final policy names (identifiers) are going to be for 11.2 and what can be influenced with them? (a short description as available from the Description field in polkit-gnome- authorization would be sufficient). I would like to mention this in the 11.2 docs about NetworkManager, but so far, I only found the one policy that relates to modifying administrator defined connections (org.freedesktop.network-manager- settings.system.modify). From your comments above I'm not sure if the names mentioned in #16 are the final ones for the newly added policies (and if the list is complete). Please advise asap as the translation deadline for this chapter is approaching. Thanks! #22: (binli) (2009-10-12 11:27:53) (reply to #20) Tanja, Just come back from holiday, sorry for late. Now this feature is still not in the upstream, I'm still working on it. I prepare to seperate the permission into more fined like, org.freedesktop.network-manager-settings.system.wireless.modify - Modify system wired connections org.freedesktop.network-manager-settings.system.wired.modify - Modify system wireless connections the description follow the policy. The #16 is now for the SLED 11-SP1 for temporary resolving usercase, I'm not sure if it could be received by upstream which is used for 11.2. So what's your translation deadline? I'll inform you when I confirm it with upstream. #23: (ta-ro) (2009-10-12 12:25:30) (reply to #22) Lin Bi, thanks very much for clarifying! :) Our localization deadline is Oct 15th but as the files have to go through language proofreading before, I have to finish the chapter today, I'm afraid. But don't worry, to be on the safe side (whatever the upstream decision may be), we can handle it as follows: for now, I'll only mention that there *are* policies for NetworkManager and where to find them in PolicyKit. We can then add more details for the next release of the docs (presumably SLE 11 SP1). #24: (ta-ro) (2009-10-12 13:18:21) (reply to #23) Removing the needinfo status. #26: Wang Lance (lzwang) (2009-11-02 08:51:11) Hi Ludwig Nussel Could you test this new functions in SLED11. I made the packages with the function. These are the URLs https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… I implemented the following policy: "org.freedesktop.network-manager-settings.system.wired.modify" "org. freedesktop.network-manager-settings.system.wireless.modify" "org. freedesktop.network-manager-settings.system.mobile.modify" "org. freedesktop.network-manager-settings.system.vpn.modify" "org. freedesktop.network-manager-settings.system.dsl.modify" "org.freedesktop.network-manager-settings.user.wired.apply" "org. freedesktop.network-manager-settings.user.wireless.apply" "org. freedesktop.network-manager-settings.user.mobile.apply" "org. freedesktop.network-manager-settings.user.vpn.apply" "org.freedesktop. network-manager-settings.user.dsl.apply" . And *.modify are the policy for the editing adding and deleting of the system connections. And *.apply are the policy for applying the user connection to activate the devices. You can see the default settings in /usr/share/PolicyKit/policy/org. freedesktop.network-manager-settings.system.policy, which make the NM behave like the one without those policy. Thanks, Lance Wang #27: Ludwig Nussel (lnussel) (2009-11-03 16:17:45) (reply to #26) I've tried it on openSUSE 11.1 now. Works great AFAICT. However I think the usability could be enhanced by creating system connections by default, at least when user connections are restricted. That way the user would not need to authenticate each time he wants to connect. wrt separate policy for shared connections, I think that should be doable by checking another condition in is_user_request_connection_type_authorized(), right? #28: Wang Lance (lzwang) (2009-11-06 10:52:31) (reply to #27) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1. Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2. Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager- settings.system.*.modify. 3. In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4. Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he have the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1. If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2. If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3. If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org. freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #29: Wang Lance (lzwang) (2009-11-06 11:02:46) (reply to #27) (sorry. repeat reply for missing format) Hi Ludwig I have a look at the request "creating system connections by default". I think it could not be done like that. 1) Connections created by the users include personal secrets which should not be saved in system scope without the permission of the owner. Because in the NetworkManager the password in system connection is saved without encrypted. 2) Saving a connection as a system one means another authentication which control by org.freedesktop.network-manager-settings.system.*. modify. 3) In the NetworkManager 0.7 activation of a system connection will not ask the console user about any kind secrets settings. That will make user confused if he types the wrong password first time. 4) Maybe it can be implemented in the way that after the user connection is successfully applied, the nm-applet change the user connection to a system connection. But the way is very ugly I think. And there is a way the user would not need to authenticate each time he wants to connect if he has the privilege of modifying system connection. He can change a connection scope from user to system in nm- connection-editor. 1) If the computer is a personal one, the user who is the administrator can set all the policy settings to default. That NetworkManager can apply any kind connection. 2) If the computer is centrally controlled, the administrator is responsible for settings the default system connections for all users. 3) If there is specific user should be given some privileges, the administrator can set them in the polkit. wrt separate policy for shared connections, yes they are doable. I think the policy should be like these org.freedesktop.network-manager-settings.user.*.share . And how do you think the default settings of these policy ? #30: Ludwig Nussel (lnussel) (2009-11-06 11:09:33) (reply to #29) Ok. I already suspected that the system setting thing is hard to do with NM's architecture. Wrt share settings I'd set them to auth_admin_keep_always by default. However, the settings you add to the package get overwritten by polkit- default-privs anyways to be able to use different settings for 'standard' and 'restrictive'. + #31: Wang Lance (lzwang) (2009-11-11 11:49:59) + Hi Ludwig + The version with shared connection is ready. These are + https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… + https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… + https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… + The policy added are org.freedesktop.network-manager-settings.user.*.apply- + with-share. What should be mentioned is that the shared connection is + only controlled by these. In other words org.freedesktop.network- + manager-settings.user.*.apply do not control the shared connection. + Thanks, + Lance Wang + -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFATE 305883] Install and boot support for MDRAID External Metadata (ISW)
by fate_noreply＠suse.de 10 Nov '09

10 Nov '09

Feature changed by: Arvin Schnell (aschnell) Feature #305883, revision 25 Title: Install and boot support for MDRAID External Metadata (ISW) openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-09-10 10:23:06 reject reason: too late for 11.2 Priority Requester: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Support for MDRAID External Metadata ISW for raid 0, 1, 10 and 5, 6 (??). User should have a choice between DMRAID and MDRAID or have no DMRAID support. This feature request has three aspects: 1) Detection of RAID arrays and platform capabilities Currently SLES can detect raid arrays but it does not confirm whether raid is enabled in the platform BIOS. If raid support has been disabled in the BIOS then arrays should not be presented as candidates for installation Currently "mdadm --detail-platform -e imsm" could be used for this detection as it returns true when the platform has Intel(R) Matrix Storage Manager support enabled. 2) Creating an initrd with support for assembling ISW raid arrays This has dependencies on how FR#781 is resolved (mdp versus kpartx) and needs support for handling the metadata dirty bit FR#782. At a minimum it involves adding something akin to the following commands to the initrd init script: ... mdadm -Asc mdadm.conf mount /dev/md/Volume0p1 /sysroot mdmon --switch-root /sysroot /dev/md/imsm0 ... 3) Installing the bootloader on a RAID device Fortunately the version of grub in SLES11-beta6 seems to already understand/expect partitionable md arrays as the following grub commands: root (hd0,0) setup (hd0) ...ends in a failure to access /dev/md/Volume0p1. So this may add weight to the mdp case for FR#781. Adding a link to the kpartx partition, that SLES11 currently creates, allows this to grub installation to complete successfully. However, this required hand editing of /boot/grub/device.map so the final solution will probably require a utility to dump the grub device to raid device mapping, or the restriction that the raid device must be grub device (hd0). Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #6: Matthias Eckermann (mge1512) (2009-09-07 13:08:16) As long as Intel is helping us, we should not reject this. + #11: Arvin Schnell (aschnell) (2009-11-10 11:55:12) + I have now merged the code from Intel to the YaST SLE11 SP1 code. + Unfortunately there are still some open issues discovered lately during + development, e.g. modification to mdadm.conf and support for udev ids. + Also the code has never been tested during installation so expect bug + reports. -- openSUSE Feature: https://features.opensuse.org/305883

1 0

[openFATE 306326] mount encrypted /home before user config
by fate_noreply＠suse.de 10 Nov '09

10 Nov '09

Feature changed by: Ludwig Nussel (lnussel) Feature #306326, revision 23 Title: mount encrypted /home before user config openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Description: Taken from bugzilla, requested by development. When installing with an encrypted /home partition I am informed during user creation that the /home partition is not mounted (see screenshot in bugzilla). What is missing here is the possibility to enter the password for the partition, mount the partiton and continue with the user configuration. Relations: - mount encrypted /home before user config (novell/bugzilla/id: 456004) https://bugzilla.novell.com/show_bug.cgi?id=456004 Discussion: #1: Stephan Kulow (coolo) (2009-06-24 12:37:08) according to the bugzilla, it's a cryptsetup feature. #2: Ludwig Nussel (lnussel) (2009-07-07 13:11:13) The default timeout for partitions is two minutes. If some partition should not have a timeout the option 'timeout=0' needs to be specified in crypttab. I would not recommend to do that by default for any partition though. I could set the timeout to 0 if /var/lib/YaST2/runme_at_boot is present to have an exception for 2nd stage install. #4: Matthias Eckermann (mge1512) (2009-08-17 15:12:20) @Stefan - where should the password/passphrase be entered: cmdline or YaST (2nd stage)? #6: Stefan Behlert (sbehlert) (2009-08-21 13:48:05) (reply to #4) Comment 2 sounds like a valid aproach. #8: Stefan Behlert (sbehlert) (2009-09-23 07:50:21) Marcus, any update? #9: Ludwig Nussel (lnussel) (2009-09-23 09:45:55) implemented in Factory as described in comment #2 + #13: Ludwig Nussel (lnussel) (2009-11-10 11:24:52) (reply to #12) + done for sle11sp1 -- openSUSE Feature: https://features.opensuse.org/306326

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 10 Nov '09

10 Nov '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #306315, revision 9 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... + At the very least (and that's the M below for 11.3) we should inclrease + the interval with which PK grabs the Big Lock. References: http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html https://bugzilla.novell.com/show_bug.cgi?id=551761 Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) Even if one zypp app is running, one should still be able to use the other in read-only mode (searching, reporting needed updates from current metadata, etc.). #3: Ralph Ulrich (ulenrich) (2009-11-07 01:01:08) This would be really cheap a read only zypper: rypper: only read only action enabled Benefit: I can do some working tasks with zypper and while this works I am able to inform myself using: rypper se -s something #4: Federico Lucifredi (flucifredi) (2009-11-10 04:29:58) Probably looking at the frequancy with which PK grabs the Big Lock is worth doing... I don't care to be notified by a popup within five minutes of an update being released if that means that most of the time my zypper calls bump into the big-lock-surprise. Yast is a non-issue, people can figure out to close it. it is the PK grabbing that is annoying, and is equally on RHEL (YUM) and SLES (zypper), we should tone down the frequency of its checks. -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 10 Nov '09

10 Nov '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #306315, revision 8 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... References: http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html https://bugzilla.novell.com/show_bug.cgi?id=551761 Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) Even if one zypp app is running, one should still be able to use the other in read-only mode (searching, reporting needed updates from current metadata, etc.). #3: Ralph Ulrich (ulenrich) (2009-11-07 01:01:08) This would be really cheap a read only zypper: rypper: only read only action enabled Benefit: I can do some working tasks with zypper and while this works I am able to inform myself using: rypper se -s something + #4: Federico Lucifredi (flucifredi) (2009-11-10 04:29:58) + Probably looking at the frequancy with which PK grabs the Big Lock is + worth doing... I don't care to be notified by a popup within five + minutes of an update being released if that means that most of the time + my zypper calls bump into the big-lock-surprise. + Yast is a non-issue, people can figure out to close it. it is the PK + grabbing that is annoying, and is equally on RHEL (YUM) and SLES + (zypper), we should tone down the frequency of its checks. -- openSUSE Feature: https://features.opensuse.org/306315

1 0

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

09 Nov '09

Feature changed by: Ján Kupec (jkupec) Feature #120340, revision 121 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. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[New: openFATE 308316] Add task-oriented view to YaST
by fate_noreply＠suse.de 08 Nov '09

08 Nov '09

Feature added by: Bart Otten (BartOtten) Feature #308316, revision 1 Title: Add task-oriented view to YaST openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Bart Otten (bartotten) Description: Maybe we should copy the 'basic & advanced view' from Microsoft Windows. The basic (task oriented) view drives me crazy but my mom loves it ;-) From the newbie/noob point of view this would make systemconfiguration a lot easier. Example: http://windows-server-training.com/wp-content/uploads/2008/08/tcp_ip_static… -- openSUSE Feature: https://features.opensuse.org/308316

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 08 Nov '09

08 Nov '09

Feature changed by: Bart Otten (BartOtten) Feature #302306, revision 71 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) 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. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) For what's worth, things got worse in the meantime ;) This feature needs to be split into 2 or 3 subfeatures: * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). * Reorganize groups: Move items from "Other" to Miscellaneous, split Network Services into Network Servers and Network Clients, make the Apparmor entries one entry and move it to Security, make Virtualization entries one entry and move it to System, move Hostnames from Network Services to Network Devices and rename Network Devices to "Network Devices and Hostnames". * Improve the UI. The Gnome CC is rahter pointless because its left navigation (?) is just superfluous (ok, there is now "Common Tasks"...). Because YaST contains more groups and especially entries, we need a way to hide or collapse groups completely. (I do not like the KDE idea just to display a subset of the entries of a group.) BTW, the worst thing about yast's gtk ui is the idea of sorting groups alphabetically. In English, happily "Hardware" comes before "Miscellaneous"... + #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) + +1 + The AppArmor-group is annoying me for a long time. When it came into + openSUSE I allready filed a bugreport (FATE was not openFATE yet). I + think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

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

08 Nov '09

Feature changed by: Bart Otten (BartOtten) Feature #120340, revision 120 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... #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. -- openSUSE Feature: https://features.opensuse.org/120340

1 0