|
Bugzilla – Full Text Bug Listing |
| Summary: | [Fate 300960]Updating system to newer packages is too complicated | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Stephan Binner <stbinner> |
| Component: | YaST2 | Assignee: | Stefan Hundhammer <shundhammer> |
| Status: | RESOLVED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | andreas.hanke, jsrain, suse-beta |
| Version: | Alpha 4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Stephan Binner
2005-12-21 12:03:09 UTC
Which updates are we talking about? If you use YOU, there is an easy way to install all updates which are relevant for your system... your suggestion is about the packager, I will reassign it to the maintainer, Jiri, respectively. What about using "system update" instead of "install/remove software"? ;-) (names may differ a bit because I translated them from german to english) Honestly I never tried "system update" for that, did you? But I hear that it's basically unmaintained and I read that people have/had problems when wanting to update to packages from supplementary (someone wrote about kernel being resetted to DVD version!?) with it. There must be IMO a reason that there are many tutorials about updating out there and that all I know describe above way (proven best practice?). I miss the insight if/how above and "system update" functionality differ, Jiri or Klaus should be able to judge this wish better. :-) (In reply to comment #3) > Honestly I never tried "system update" for that, did you? Not for the KDE update - but I just started it for a short test with KDE supplementary (mirrored to my harddisk) and packman as additional install sources. (Result: It suggested some upgrades of packman packages (good) and a downgrade of the kernel package (not so good).) > But I hear that it's basically unmaintained Huh? It looks like the installation system when booting from CD/DVD... > and I read that people have/had > problems when wanting to update to packages from supplementary (someone > wrote about kernel being resetted to DVD version!?) with it. Strange - but I could just reproduce it :-( (bugreport already exists: bug 117461) However, the kernel package was the only one - other packages were not suggested for downgrade... Please note that this problem has nothing to do with supplementary or packman - it even appears if I switch off all installation sources except the 10.0 retail DVD. > and I read that people have/had
> problems when wanting to update to packages from supplementary (someone
> wrote about kernel being resetted to DVD version!?) with it.
I can confirm that happens. It happens everytime I use System Update to upgrade KDE. That is why, after I run System Update I need to run Online Update to reinstall the latest kernel.
Uh - there is a reason why we don't offer a 2- or 3-click method for this kind of thing. It's outright dangerous to do it. You may be lucky, but then, you may be not. That's what we have "system update" for - from a boot medium (!), not from within the installed system. "System update" provides the workflow to do it right, not just hoping to be lucky like updating all single packages. This method is OK if you want to update, say, all KDE packages or all development packages or somethign like that. If OTOH you want to update your complete system, you might get stuck if at some point during the update some packages that do the update are updated to versions that are no longer as compatible with the old system as you wish they were. In that case, you'll end up with a wrecked system. IMHO, YaST should offer such a method now. I agree it didn't make sense in previous versions since we never published updated RPMs standalone but only enclosed within patches. This has changed now and the update repositories do offer newer RPMs. Especially with openSUSE and 'living' on the factory tree, such an easy method is needed. That said, YaST should apply some safety measures. Esp. checking the distribution. Newer distributions might include incompatible changes (i.e. new glibc, new compiler, etc.) which need a proper update as explained in comment #7 above. IIrc, yast2-update already applies such methods. As a workaround use 'rug up' which provides the requested functionality. However, it upgrades based on version comparison alone without checking the distribution. I made a feature entry for this -> #300960 We will need a workflow for that. There is more to it than just changing the status of all installed packages to "update". Just think of package splits, obsoletes, new packages. I doubt the simplistic approach will make anybody happy. Splits and obsoletes are only allowed when the distribution changes. Just offering a "update on higher version" (with the above mentioned safety measures applied) would make a lot of people happy. (In reply to comment #11) > Splits and obsoletes are only allowed when the distribution changes. Hmm, what about the mozilla -> seamonkey replacement via YOU? ;-) Thats a patch, not a normal package update because of higher version. If I understand this enhancement request correctly, it asks for a plain "update all packages which are installed and a higher version is available" function. Thats basically what "rpm -F..." does. It explicitly does not introduce new packages. Old packages might get deleted due to obsoletes though. AFAICS this is only the first step of it, and probably more because most people who do this now either know what they are doing and do manual things like described in comment #12 manually or because they don't see the problem. But experience shows that nobody will be content with the "just barely fullfilling requirements" approach. If we support that kind of thing, we should support it all the way and not withdraw behind the line of fine print. We will get bug reports if we don't do it right, and not only will the users filing those bug reports not be the same as those who wanted and would have been content with the minimal approach, they will also be morally right. Let's do it right or not support it at all. Anything in between doesn't make very much sense. reopening The functionality is now there (with openSUSE 10.2). I doubt, however, that anybody will be really happy with it. |