January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Andrey Karepin (EGDFree) Feature #305634, revision 30 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Alexey Gaponik (hedgehog77) Interested: Andre Duffeck (aduffeck) + Interested: Andrey Karepin (egdfree) Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Richard Weinberger (derrichard) Interested: Robert Davies (robopensuse) Interested: Sebastian Rösgen (palimpseste) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Karsten König (remur) Feature #305168, revision 8 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Interested: Guy Lunardi (glunardi) Interested: Jan Kara (jankara) + Interested: Karsten König (remur) Interested: Marcus Meissner (msmeissn) Interested: Robert Davies (robopensuse) Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Alexey Gaponik (hedgehog77) Feature #305634, revision 29 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) + Interested: Alexey Gaponik (hedgehog77) Interested: Andre Duffeck (aduffeck) Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Richard Weinberger (derrichard) Interested: Robert Davies (robopensuse) Interested: Sebastian Rösgen (palimpseste) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

19 Jan '09

Feature changed by: Karsten König (remur) Feature #304879, revision 22 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. Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Binner (beineri) Interested: Bernhard Friedreich (bernhard1234) Interested: Johann-Nikolaus Andreae (jnandreae) + Interested: Karsten König (remur) Interested: Markus K (kamikazow) Interested: Maxi Schimmel (maxxs) Interested: Ruchir Brahmbhatt (ruchir) 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

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

19 Jan '09

Feature changed by: Karsten König (remur) Feature #300758, revision 43 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. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable 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 Priority Requester: Important 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. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) Interested: Andrey S (seld) Interested: Bernhard Friedreich (bernhard1234) Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Pedro Canovas (pedrogeek) Interested: Rémy Marquis (spyhawk) Interested: Ruchir Brahmbhatt (ruchir) Interested: Santiago Hirschfeld (jsantiagoh) Interested: Stefan Ott (steve_odd) 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. + #11: Karsten König (remur) (2009-01-19 10:09:49) + How about using rpmorphan, I agree with flucifredi about the command + line idea... http://rpmorphan.sourceforge.net/ + And otherwise you could use their system to find orphanized packages + and display them in yast but make clear that deleting -all orphanized + packages will also delete the ones explicitly installed... (it only + detects wether the package fullfiles any requirement...) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

[openFate 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Stefan Assmann (assmannst) Feature #305586, revision 12 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Interested: Alexander Graf (algraf) Interested: Garrett LeSage (glesage) Interested: Guy Lunardi (glunardi) Interested: Jakub Rusinek (liviopl) Interested: Jared Allen (jpallen) Interested: Matthias Eckermann (mge1512) Interested: Ruchir Brahmbhatt (ruchir) Interested: Siegfried Olschner (sdolschn) Interested: Stefan Fent (sfent) Interested: Tejun Heo (teheo) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. #6: M. S. (funkym) (2009-01-17 13:05:51) libnotify does all that and ontop is based on a desktop independent freedesktop specification (http://galago-project.org/specs/notification/index.php) for notifications to adopt by any desktop environment. It is written in C which is much more suitable for daemons and provides bindings for D- BUS, Mono, Python and Vala. Interactive notifications are already used widely; take PackageKit as an example. The developer of growl is also interested to improve libnotify as they are closely related and friends with the maintainer. A cross desktop friendly notifications utility in Python is the right thing to make things worse. If you want the bling just create a different theme for libnotify... What libnotify needs though is a bit of coding love to implement stuff like network notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES! $2c + #7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6) + It's no longer the question whether to switch from one to the other. + Mumbles is able to intercept libnotify messages so we can provide it + "on top" and switch. Then it's a question of defaults and what we like + this to become. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305586

1 0

[openFate 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305622, revision 7 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: (iaW) update to tar 1.21 + Discussion: + #1: Jan Engelhardt (jengelh) (2009-01-19 09:32:51) + tar --use=lzop -cf foo.tar.lzop -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305622

1 0

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

19 Jan '09

Feature changed by: Robert Munteanu (robert_munteanu) Feature #120340, revision 43 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 Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> 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(a)novell.com> 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(a)novell.com> reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Interested: Bernhard Friedreich (bernhard1234) Interested: Ján Kupec (jkupec) Interested: Lukas Ocilka (locilka) Interested: Robert Davies (robopensuse) + Interested: Robert Munteanu (robert_munteanu) Interested: Ruchir Brahmbhatt (ruchir) 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 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Dean Hilkewich (deanjo13) Feature #303678, revision 12 Title: New yast module - LIRC configuration openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-24 15:31:30 reject reason: More urgent stuff to cover. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) + Interested: Dean Hilkewich (deanjo13) Interested: Jakub Rusinek (liviopl) Interested: Maxi Schimmel (maxxs) Partner organization: openSUSE.org Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303678

1 0

[openFate 304429] Package cache handling in yast
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Victor Prosolin (prosolin) Feature #304429, revision 9 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Interested: Duncan Mac-Vicar (dmacvicar) + Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304429

1 0

[openFate 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Victor Prosolin (prosolin) Feature #305622, revision 6 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) + Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: (iaW) update to tar 1.21 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305622

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 19 Jan '09

19 Jan '09

Feature changed by: Victor Prosolin (prosolin) Feature #305634, revision 28 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Richard Weinberger (derrichard) Interested: Robert Davies (robopensuse) Interested: Sebastian Rösgen (palimpseste) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) + Interested: Victor Prosolin (prosolin) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

19 Jan '09

Feature changed by: Victor Prosolin (prosolin) Feature #304911, revision 11 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. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Interested: Guy Lunardi (glunardi) Interested: Klaus Kämpf (kwk) Interested: Luuk de Waal Malefijt (tails9) Interested: Marcus Kraft (marcuskraft) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Security Team (secteam) + Interested: Victor Prosolin (prosolin) 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 Discussion: -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304911

1 0

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

19 Jan '09

Feature changed by: Victor Prosolin (prosolin) Feature #302923, revision 18 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 Priority Requester: Neutral 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. Priority Requester: Neutral openSUSE-11.2: Evaluation Priority Requester: Neutral 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) Interested: Ruchir Brahmbhatt (ruchir) + Interested: Victor Prosolin (prosolin) 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 305489] default email in email applications
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Carlos Lange (cflange) Feature #305489, revision 8 Title: default email in email applications openSUSE-11.2: New Priority Requester: Desirable Requested by: Martin Lasarsch (mlasars) Interested: Andrey Karepin (egdfree) + Interested: Carlos Lange (cflange) Interested: Joe Brockmeier (jbrockmeier) Interested: Vasiya G. Znaydyuk (-karlson-) Partner organization: openSUSE.org Description: To get more subscriptions to the mailinglists it would be nice to have a "default mail" in the mail clients (evolution, kmail) which points the user to the mailinglists. Every openSUSE user should be subscribed to opensuse-announce at least. A simple reply to this "default mail" should subscribe to the list. Of course there could be more information in it, like other important lists, pointing to the main list page. evolution have already a "default mail", with general information about evolution, kmail afaik not. This might be also usefull for OEM customers to have a welcome mail for the customers, pointing to the support pages etc.. So general email "branding" packages which makes it possible to have such special "default mails" for the email clients would be usefull. Discussion: #1: Carlos Lange (cflange) (2009-01-17 19:59:30) There are several parts to this suggestion. 1) "default mail": If you mean "Default" in the sense that when I start a new message the To: field is filled out by default with the mailing- list address, I disagree with your comment. The user should set that and an inexperienced user should find herself/himself subscribing to a mailing-list by mistake, just because they forgot to reset the To: field. Such a user would be rightly upset and feel like they were trapped into doing it. 2) If you mean, however, that the address book in Evolution and Kmail should be pre-populated with relevant addresses, such as the mailing- list and others, in the same way the Firefox bookmarks toolbar comes pre-populated with the SUSE folder, then I would agree that this is a useful suggestion, because the user can freely choose to use those addresses or not. 3) I strongly disagree that every openSUSE user should be subscribed to the opensuse-announce mailing-list. I deal with many different types of users. Only a minority of them would be interested in receiving announcements and they actively subscribe to the mailing-list. The vast majority of them likes the Linux-way of being non-intrusive, without the nags and unsolicited messages from the proprietary world, that tend to be associated with annoying marketing strategies. Please, don't advocate that for openSUSE. The SUSE information box shown at the first login is as much in-your- face direct marketing as one should need to take when using openSUSE. And being beautiful and carefully designed as it is, it contains all information a new user needs to decide how much involved with the operating system they want to be. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305489

1 0

[openFate 303367] Better Beagle Acceptance
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #303367, revision 13 Title: Better Beagle Acceptance openSUSE-11.0: Rejected by Gary Ekker <gekker(a)novell.com> reject date: 2008-05-27 09:03:27 reject reason: Not done for 11.0. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger (a_jaeger) + Interested: Sebastian Rösgen (palimpseste) Partner organization: openSUSE.org Description: There have been several discussions on the public openSUSE mailing lists, e.g. http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where people complain about resource usage or garbage from beagle. I suggest that we analyze the current situation and check where are real problems and consider solutions. One option would be to make it easier for users to not enable beagle on their systems. Note: The feature request is about getting a better acceptance by our users of our indexing technology - and therefore let's figure out what are the problems they are hitting in real life. References: https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Andreas Jaeger (a_jaeger) (2008-01-20 11:12:58) See also bug 282678. #2: Andreas Jaeger (a_jaeger) (2008-01-23 16:23:51) Note: powertop advises "Suggestion: Disable or remove 'beagle' from your system. Beagle is the program that indexes for easy desktop search, however it's not very efficient and costs a significant amount of battery life.". #3: JP Rosevear (jproseve) (2008-01-23 10:38:58) (reply to #2) Yes, this is well known and was covered extensively last year and caused by polling for battery status in some cases. 0.3.2 uses hal to detect battery status: http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html #4: JP Rosevear (jproseve) (2008-01-23 10:41:35) (reply to #3) Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.… -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303367

1 0

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

18 Jan '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #304937, revision 7 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. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important 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) + Interested: Sebastian Rösgen (palimpseste) 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: -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304937

1 0

[openFate 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305147, revision 4 Title: Wizard mode for Network Card configuration (in YaST) openSUSE-11.2: New Priority Requester: Neutral Requested by: Michal Zugec (mzugec) + Interested: Sebastian Rösgen (palimpseste) Partner organization: openSUSE.org Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305147

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305634, revision 27 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Richard Weinberger (derrichard) Interested: Robert Davies (robopensuse) + Interested: Sebastian Rösgen (palimpseste) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 305535] Improve samba yast modules
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305535, revision 4 Title: Improve samba yast modules openSUSE-11.2: Evaluation Priority Requester: Important Requested by: James McDonough (jmcdough) Interested: Jiří Suchomel (jsuchome) Interested: Lukas Ocilka (locilka) + Interested: Sebastian Rösgen (palimpseste) Partner organization: openSUSE.org Description: Improve the design of the yast samba modules. More details to come. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 Business case (Partner benefit): openSUSE.org: Many customers report difficulties with various areas of samba yast administration, both with new features requested and layout of current ones. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305535

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Richard Weinberger (derRichard) Feature #305634, revision 26 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) + Interested: Richard Weinberger (derrichard) Interested: Robert Davies (robopensuse) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

18 Jan '09

Feature changed by: Johann-Nikolaus Andreae (jnandreae) Feature #304879, revision 21 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. Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Binner (beineri) Interested: Bernhard Friedreich (bernhard1234) + Interested: Johann-Nikolaus Andreae (jnandreae) Interested: Markus K (kamikazow) Interested: Maxi Schimmel (maxxs) Interested: Ruchir Brahmbhatt (ruchir) 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

[openFate 100048] MySQL Configuration
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Bernhard Friedreich (Bernhard1234) Feature #100048, revision 25 Title: MySQL Configuration openSUSE-10.3: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2007-07-16 19:10:56 reject reason: Too late for 10.3. Priority Requester: Desirable openSUSE-11.0: Rejected by Duncan Mac-Vicar <dmacvicar(a)novell.com> reject date: 2008-03-18 12:42:12 reject reason: We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-06-26 16:11:49 reject reason: Out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Lukas Ocilka (locilka) + Interested: Bernhard Friedreich (bernhard1234) Interested: Holger Dyroff (escubar) Interested: Michal Hrusecky (-miska-) Partner organization: openSUSE.org Description: MySQL is used very often on servers. There should be management tool for databases, and database-users and for some mysql-variables (key_buffer, write_buffer and more). Discussion: #1: Lukas Ocilka (locilka) (2005-11-29 15:46:59) Novell to Offer MySQL Network * http://www.mysql.com/news-and-events/press-release/release_2005_28.html * Novell offers affordable database software and support services through 'MySQL Network' subscriptions #2: Gerald Pfeifer (geraldpfeifer) (2006-01-03 14:03:13) Holger, can you please qualify this from a PM perspective? (Not for CODE10, of course, but CODE11 or SL10.2/10.3, for example.) #5: Duncan Mac-Vicar (dmacvicar) (2008-03-18 12:41:18) We don't have the resources to finish this module. I will move it to http://en.opensuse.org/Summer_of_Code_2008#YaST_ideas -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=100048

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 18 Jan '09

18 Jan '09

Feature changed by: Bernhard Friedreich (Bernhard1234) Feature #305634, revision 25 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) + Interested: Bernhard Friedreich (bernhard1234) Interested: Bruno Friedmann (bruno_friedmann) Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Mario Carrion (mariocarrion) Interested: Markus K (kamikazow) Interested: Matthias Eckermann (mge1512) Interested: Maxi Schimmel (maxxs) Interested: Robert Davies (robopensuse) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

18 Jan '09

Feature changed by: Bernhard Friedreich (Bernhard1234) Feature #300758, revision 42 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. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable 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 Priority Requester: Important 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. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) Interested: Andrey S (seld) + Interested: Bernhard Friedreich (bernhard1234) Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Pedro Canovas (pedrogeek) Interested: Rémy Marquis (spyhawk) Interested: Ruchir Brahmbhatt (ruchir) Interested: Santiago Hirschfeld (jsantiagoh) Interested: Stefan Ott (steve_odd) 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