Feature changed by: Andreas Jaeger (a_jaeger) Feature #307137, revision 2 Title: possible installation improvements - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-08-13 13:17:56 + reject reason: Too late for 11.2 - and please refile for 11.3 as single + separate features so that we can discuss them independently. Priority Requester: Desirable Requested by: John Pemberton (toes) Description: I've searched openFATE for feature suggestions such as these, and I didn't seem to find them. I hope these aren't duplicates. I've used SUSE for several years. For some years I purchased what was the "Professional" version, and more recently I've downloaded the "open" form of it, up through 11.1. I've long liked it, but there are a variety of installation improvements that I feel would make things easier. I've also noticed a variety of installation issues that have occurred with more recent open versions. Since there doesn't appear to be very detailed documentation in some cases, some of these may actually be design flaws or bugs. But without the detailed design docs., etc., I couldn't evaluate that. Since a lot of this occurred some time ago, I can't give specific examples, or logs, etc., but I can at least describe what happened conceptually. - Partioning ======= the easiest scenario for the suse install procedure to handle seems to be a new installation on an empty disk. But with existing partitions in place, things seem to get a bit confusing. I've actually seen installation partition proposals involving several deleting and creating partition actions, that could have been handled with just a couple partition changes to achieve the same result, especially in a case where I wished to save some existing partition(s). When I ask for an LVM based proposal instead of a physical drive based proposal, I often have to ignore the proposal which is often even more involved than an original drive based proposal. Especially if I already have an existing volume group on a different drive that I wish to keep. In fact, I believe in a multi-drive machine I've seen the install ignore what I'd already selected as the drive on which to install, when I requested a change to an LVM based proposal. Had I approved the proposal, the existing system would have been well and truly munged. Since software doesn't have higher level Human cognitive abilities, I realize that it might be hard to write "static" software that can anticipate every possible partitioning issue, especially to realize that the same partitioning goal can be accomplished in a much simpler way. Perhaps the partitioning desires of the User could be interpreted at a higher level, such as hints, which are applied regardless of which type of proposal is requested. In fact, perhaps a variety of partitioning issues could be handled by the use of a *simple* inference engine to simplify partitioning proposals and factor in hints from the User? - SATA vs. PATA in a mixed machine ======================== I've seen the rescue system, and I believe the repair mode as well as the main install mode, try to treat both SATA and PATA in the same machine with a SCSI mapping, and it wasn't able to successfully handle the PATA drive in that way ( based on examining the logs ). The system would appear to work very slowly during install ( or hang ). I was forced to remove the PATA drive, then install on the SATA. Oddly, once the full blown installed system was running, I was able to add the PATA drive to it and it worked fine. It would be really great to make those installation environments/modes able to more fully support the same range of hardware as the fully installed system. After all, how can the rescue system, or the repair mode, function fully if they can't support the same range of hardware as the installed system? - Provide a true upgrade/update path ========================= I have seldom been able to upgrade the version of suse that I have installed, seemlessly, or without a pretty large manual effort. Often if a path from one version of another is recognized as a potential update path by YAST, something during the install fails. Often this seems to be due to a difference in how files are split across packages, or package name changes. Sometimes there doesn't even seem to be a recognition that a particular direction in file versions such as from KDE 3.x to KDE 4.y, is an upgrade path. In some cases, problems in updating have been to do a change in configuration file formats or features in particular applications. As time has gone by, some applications have provided ways to import some things from older versions, e.g. bookmarks from an older Firefox, mail from an older Kmail, etc. But there are still quite a few things have have to be moved over manually or just plain recreated, e.g. mail message status, accounts/identities in Kmail, etc., plenty of configurations for plenty of applications. I realize that some of this, perhaps a lot of it, may derive from changes in the applications themselves, for applications that are created elsewhere and just integrated into suse. But perhaps the necessary information to map such changes across versions, could be obtained from the various outside application owners to allow a more smooth/automatic upgrade path within opensuse. - 1-click installs ========== During a 1-click install I'd expect that quite a few sources of installation would have to be changed. E.G., some "Build Service" packager, or some such, would replace the original packager as the source of a package. But I've run into situations, e.g. while trying to upgrade to KDE 4.2, where I had to approve literally dozens of such changes via "conflict resolution", individually . I would suggest it would be a lot nicer if those changes would be automatic in the 1-click installs, since it is part of the spirit of a 1-click install. - Repeated timeouts during installation ========================== During different installations using different ISP's in different areas of the U.S., I've experienced numerous repeated timeouts while trying to download packages. The problem is temporarily overcome by just retrying the download. But it can happen dozens and dozens of times during a single installation, e.g. during the initial on-line update. In most cases the message indicated that the hostname could not be resolved. Are the DNS servers on the repository end overloaded? If so, can they be enhanced? Or is there a timeout on the client end that could be increased? Perhaps a good enchancement would be to allow a User to specify a timeout on the client side? - Duplicate repository names =================== During the installed life of openSUSE 11.1 on my machine, I have added at different times, virtually every repository on the community repositories list. There appear to be duplicates. I you look at "Configured Software Repositories" in yast and sort by URL, you can see there are a few with different names but the same URL. By name the dups would be e.g. "Main Repository (DEBUG)" versus "openSUSE-11.1- Debug". Similarly for "SOURCES" and "Update". If these were meant to be repository name changes, perhaps there could be an enhancement so the client could track repository name changes. - Conflict resolution ============= When trying to interpet a lengthy list of package conflicts that need resolving, it can be very time consuming trying to separate one from another because they seem to run together. I would suggest a very useful enchancement would be extra blank lines between each conflict description. Sometimes I have felt the description of the choices for resolution could be more clear as well, perhaps aligning the indented choices would further improve readability of the description. - yast user event handling ================= It may be yast's X event loop handling or something else, but at times it feels almost like an X event loop handling problem. If yast were constructed using xview I'd talk about distinctions between implicit and explicit dispatching. But I'm not familiar with what was used to construct yast2. I've had a problem a number of times where yast seems not to be really able to process a screen button press. For example, I mouse click an abort button and yast keeps working, does not abort. Perhaps improving yast2 user event handling would be a worthwhile enhancement. - + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-08-13 13:17:13) + Please make *one* feature request per feature. -- openSUSE Feature: https://features.opensuse.org/307137