July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 12 Jul '09

12 Jul '09

Feature changed by: Luc de Louw (delouw) Feature #306327, revision 10 Title: Add DB2 Express-C openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. Relations: Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to drive the adoption of their products, even if not opensource, and as long as it doesn't affect the license/EULA/redistribution of the distribution itself, I don't see any reason not to support that initiative. IBM can choose to either have it in the non-OSS repository, or host it in a repository of their own, with openSUSE builds. What is involved on our side of things ? #5: Robert Schweikert (rjschwei) (2009-05-28 09:21:00) - IBM has a distribution agreement that needs to be signed. In addition I think when somone installs DB2-Express C from the non-oss repo we should pop up a box telling them about the agreement if they intend to distribute DB2 Express with a product. No registration required for private use. #6: Robert Schweikert (rjschwei) (2009-05-28 09:22:04) Added attachment Distribution agreement (IBM_DB2_and_WAS_CE_Distribution_Form_and_Agreement_4_17_2009.pdf) + #7: Luc de Louw (delouw) (2009-07-12 14:45:45) + It is a good idea to add DB2-Express. How about also to add Oracle XE + (the equivalent to DB2-Express) so users have more choice. + Should I add a feature request for Oracle XE? -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFATE 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 12 Jul '09

12 Jul '09

Feature changed by: Luc de Louw (delouw) Feature #303736, revision 10 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 + Discussion: + #1: Luc de Louw (delouw) (2009-07-12 14:43:12) + The problem is that the default reserved space is way to much for + todays diskspace available. IMHO this issue should be addressed + upstream, the default space should be much less than 5% or even a fixed + amount of space e.g. 100MB. + The reserved space for root is tought for emergencies and not for + installing new packages, at least not with that size. + At the end of the day it is not a good idea to support that feature. -- openSUSE Feature: https://features.opensuse.org/303736

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 11 Jul '09

11 Jul '09

Feature changed by: Vincent Petry (PVince81) Feature #304429, revision 15 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) 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) 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 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) 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) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) Yes. it is working. As specified above, there is a new checkbox in the UI for enabling cache handling. + #5: Vincent Petry (pvince81) (2009-07-11 03:20:54) + Will it also resume partially downloaded packages ? -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 306621] Possibility to skip filesystem check at startup
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Dominik Grafenhofer (dgrafenhofer) Feature #306621, revision 1 Title: Possibility to skip filesystem check at startup openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominik Grafenhofer (dgrafenhofer) Description: Periodic filesystem checks at startup are important, but take a lot of time. For desktop users it is sometimes importent to startup their computer really fast (e.g. when giving a presentation). It is a nuissance, that these filesystem checks cannot be easily skipped (and postponed for the next startup) like under Ubuntu. Analogous to Ubuntu Linux I therefore propose to have a mechanism in place to stop a (periodic) filesystem check at startup when the escape key is pressed during the check. -- openSUSE Feature: https://features.opensuse.org/306621

1 25

[openFATE 306758] Online Banking with New Zealand Banks
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: John Shand (jshand2008) Feature #306758, revision 1 Title: Online Banking with New Zealand Banks openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: John Shand (jshand2008) Description: I am using a financial program called KMyMoney 0.9.3. it is a fantastic program, but i am used to actually doing my online banking with another program i used for real time transactions and update ie. the program would store my login information in an encrpted file and automatically login into my Kiwibank account from the program itself. this would be an awesome feature for any of the financial software available for opensuse. please do your best with this feature as it would make life a heck of a lot easier. thanks for your help john -- openSUSE Feature: https://features.opensuse.org/306758

1 1

[openFATE 306580] provide trademark-neutral branding packages
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Juergen Weigert (jnweiger) Feature #306580, revision 1 Title: provide trademark-neutral branding packages openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Description: Wit 11.2 we plan to provide e.g. * MozillaFirefox-branding-opensuse.rpm and * MozillaFirefox-branding-upstream.rpm for the user to easily substitute our branding with an original upstream branding. This implements opensuse trademark guidelines for modified distributions, but in case of Firefox, we should also provide a * MozillaFirefox-branding-template-neutral.rpm or similar to also implement Mozilla trademark guidelines. -- openSUSE Feature: https://features.opensuse.org/306580

1 6

[openFATE 306352] mod_proxy_ajp: support for "subscribe" method
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature added by: Emmanuel Rouët (erouet) Feature #306352, revision 1, last change by Title: mod_proxy_ajp: support for "subscribe" method openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Emmanuel Rouët (erouet) Description: With mod_jk, the "unknown" methods were handled as attributes and still forwarded. In AJP, "unknown" methods are not allowed to be compressed & will not be forwarded and the connection is broken. Shouldn't AJP provide feature parity ? Currently, the list of methods supported by AJP does not include "subscribe": http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html#overviewprotocol However, Apache.org states "Later version of ajp13, will transport additional methods, even if they are not in this list." -- openSUSE Feature: https://features.opensuse.org/306352

1 1

[openFATE 306393] BrowsePoll support in yast2-printer
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306393, revision 3 Title: BrowsePoll support in yast2-printer - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-07-10 11:41:21 + reject reason: A complete redesign is too much work for this feature. Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Description: yast2-printer "Print via Network": request for BrowsePoll support Usually there is no need for BrowsePoll support in yast2-printer because currently it is designed to make a setup according to the "Intrinsic design of CUPS for printing in the network", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell (http://en.opensuse.org/SDB:CUPS_in_a_Nutshell) But there is a valid use case for BrowsePoll: See https://bugzilla.novell.com/show_bug.cgi?id=433047#c10 (https://bugzilla.novell.com/show_bug.cgi?id=433047#c10) I know a use-case for BrowsePoll: When in a bigger company there are several CUPS servers for various departments each server may allow access for all client hosts in the whole company but it would usually send browsing information only to the client hosts of the particular department to which a particular server belongs. When a user in department A likes to see additionally the queues on the server for department B he would use BrowsePoll to poll the queues from the server for department B. Adding BrowsePoll support requires a re-design of the whole "Print via Network" dialog. I like to have it evaluated if it is worth the effort ("business case" and so on). + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-07-10 11:42:58) + Let's not redesign the UI for this at them moment. My only requirement + is the default YaST policy: YaST should not overwrite user + configuration changes, so if a user adds BrowsePoll and later runs + YaST, the contents is still the same. -- openSUSE Feature: https://features.opensuse.org/306393

1 0

[openFATE 304500] Make storage failures non-fatal
by fate_noreply＠suse.de 10 Jul '09

10 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #304500, revision 24 Title: Make storage failures non-fatal openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 13:04:58 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:34:12 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently all storage failures (during step "Prepare Harddisk") are fatal. E.g. if a partition cannot be mounted the installation is aborted. Some failures do not really harm, e.g. if mounting of a Windows partition fails that is not used for the installation. For other failures an really experienced user might fix the problem manually on the console. So for all failures the user should be asked whether the installation should continue. References: https://bugzilla.novell.com/show_bug.cgi?id=382765#c1 https://bugzilla.novell.com/show_bug.cgi?id=397156 https://bugzilla.novell.com/show_bug.cgi?id=402812 https://bugzilla.novell.com/show_bug.cgi?id=438660 + https://bugzilla.novell.com/show_bug.cgi?id=520902 Relations: - Installation aborts after error message that NTFS partition can't be mounted (novell/bugzilla/id: 309074) https://bugzilla.novell.com/show_bug.cgi?id=309074 Discussion: #2: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:33:20) Please reject for SLE11/11.1. All resources allocated with mandatory features already. -- openSUSE Feature: https://features.opensuse.org/304500

1 0

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

09 Jul '09

Feature changed by: andrea florio (anubisg1) Feature #305634, revision 124 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) 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. Relations: - Fedora Upgrade Instructions (feature/id: http://fedoraproject.org/wiki/YumUpgradeFaq) - Debian Upgrade How-to (url: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.ht…) - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) 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. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). + #31: andrea florio (anubisg1) (2009-07-10 00:11:07) + i think that we miss something like that: + https://help.ubuntu.com/community/JauntyUpgrades + it's so easy to upgrade an ubuntu version that also my 5 years old + student was able to do it.. -- openSUSE Feature: https://features.opensuse.org/305634

1 0