RHL Severn - Initial Findings

[Jef Spaleta]

Matthew Winter wrote, somewhere in the digest:

>Once the installation was complete, I found that the system did not make
>use of the new graphical boot. I assume the installer prefers to keep
>the existing config in its entirity.

I doubt the installer keeps ALL configs as before when doing an
upgrade...i would imagine that it would really depend on what you have
editted and what is still a stock file.  rpm packages can sense custom
config files and can prefer yer custom configs over stock configs. It
really depends on what the rpm packager decided the behavior should be.
If you had a hand editted config file, rpm packages typically can either
leave that config in place and give you the stock config as a backup
file, or back up yer custom config and give you a new stock config.
Look for files like *.rpmsave *.rpmnew *.rpmold. I always forget which
type of backup file corresponds to which behavior.

>I then noticed that even though I have only installed possible 4
>additional RPM's ontop of the original RHL 9, I had alot of package
>dependency problems

...there is some value in trying to debug upgrade issues that only show
up when you are upgrading instead of doing a fresh install. Those
however are very tricky, especially dependancy issue with non-redhat
rpms that you have installed. I would have thought the installer would
throw up some warning messages about unresolved dependances for any
installed rpms that you had, even non redhat ones. This is tough to
narrow down, unless you can take the time to do repeated upgrades
scenarios where you are confident of configuration you started with. If
you have been living in rhl9 for a couple months, you could have an
extremely personalized setup that other people just might not be able to
reproduce similar upgrade bugs...its tough.

>Once booted, I attempted to install the NVidia driver, rebuilding the
>kernel. This failed as the NVidia driver performs a check of the CC
>versions and found that they are compiled using an earlier release. I
>assume NVidia will update there drivers when Severn goes into GA.

I have good news and bad news for you.
First the good news...right now becuase the kernel in the beta is still
compiled with gcc3.2 you can in fact compile the nvidia driver...you
just have to use the older gcc3.2 and not gcc3.3. In fact, you HAVE to
recompile the nvidia driver with the same version of gcc that you
compile the kernel with...so use the older Gcc3.2 which still comes in
the beta.

The bad news is...once it becomes a breeze(cough..cough) to compile the
kernel with gcc3.3, i would expect that any subsequent isos that get
released for this beta phase might have kernels compiled with gcc 3.3.
Once this happens...don't count on the nvidia driver working from that
point on..till after the beta phase is over. Nvidia has historically NOT
provided any drivers that can be used as part of the redhat beta testing
process. The problem is what nvidia gives you is mostly a binary only
library, with a small amount of code that you can recompile to work with
your kernel. Once the kernel starts being compiled with gcc3.3, the
gcc3.2 compiled library/libraries nvidia provides will most likely just
not work together. Personally i think you best serve the community if
you just use the nv driver while yer beta testing, so that you can file
bugreports for it early on, so they can get fixed sooner.  

For future reference, try not to obliterate a working system that you
expect to use with a beta. Whether or not this beta is less buggy or not
than previous betas isn't important. Always count on seeing a major
show-stopper that no-one else can reproduce, when you are installing a
beta release. Beta releases with 1400+ separate packages, will by their
very nature,always be a good source of fiber and roughage...in the form
of pointy glass shards. Beta releases will also steal your babies and
rat you out to the IRS. Just be prepared.  

And please, make sure you check and post to redhat's bugzilla about any
of the rest of these issue. I don't know if anyone can do anything about
how applications interact with on-the-fly resolution resizing(during
this beta phase at least)...but now that we have the resolution resizing
ability, applications need to start thinking about how to deal with
it....so file those bugs. I would imagine this is going to be an
application by application kind of bug that has to be sent upstream to
each of the projects themselves....but someone in the know about desktop
development could give a short explanation on where in chain desktop
resizing is suppose to be noticed.  I doubt its the wm that is suppose
to notice, so its either the desktop framework or each individual
application.

-jef"use a second partition or disk to install the beta if you can, and
leave yer rhl9 install intact to play RTCW"spaleta

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030729/fcebbb1f/attachment.sig>