Mailinglist Archive: opensuse-features (447 mails)

[fate_noreply@xxxxxxx]

Feature added by: John Pemberton (toes)

Feature #307137, revision 1
Title: possible installation improvements 
  
openSUSE-11.2: Unconfirmed
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.

  
 
-- 
openSUSE Feature: 
https://features.opensuse.org/307137