yeah i wasnt saying that i didnt know there was a new XFree. just that XFree sucks compared to xorg. they are in a sense identical, accept xorg has regular updates, and before this one it was years for xfree to update. anwya if you insist on using xfree just skip the x install and install from source when you ahve finished building the system.

edong - I have no particulr preference: in fact, I thought XFree was the standard, and I guess I was mistaken. I have no real preference one over the other. Doing a bit of reading, I now see this difference arose over a licensing dispute last year, and many distros have replaced XFree86 with X.org X server (itself based on an XFRee 86 4.4. release). Presumably S/Ware is in this camp, with the 10.0 modules at V6.7. Is this correct? I keep learning!

Looking back at my posting this is the least of my concerns.
I just don't grasp what happens to the config files in a LINUX OS upgrade.
I keep reading that new ones are created (with .new), and you have to go back and manually re-enter all changes from the /etc backup conf's you took before the upgrade (or from the .bak files the upgrade process created).
This concept has floored me, and stopped me dead in my tracks. I just can't believe that people do this. Since how can one keep track of all the OS conf file changes made over the lifetime of the use of an OS! I must be misunderstanding something totally, and have expressed these concerns in another posting, on upgrading from 9.1 to 10.0, in post 8, and esp. 9 over here at:
http://www.linuxquestions.org/questi...hreadid=331089

If you can provide guidance on that , I would be really, really grateful. Remember, I am experienced in computing, even in sysprog, but not in Linux/*IX-based systems: I profess no special expertise there; none. In this, I am a humble learner/newbie, one of the "huddled masses yearning to breathe free..."

Regardless, once I have established how it is done, I will be ready to move ahead, and upgrade. As I said, the "X" thing can be done either way, and is not important to me...
George

Well, it is and it isn't the best side of Linux ( ) but yes, you've to upgrade the .new config files manually.
BUT these config files are often the same, nothing changes, so most of the times it's not necesary to replace them (unless they've changed the config file format which doesn't happen too often). Just take a quick look or use the diff tool to see the diferences, and decide what to do.
Finding new config files is easy too, and at least on my experiences, the new files were just a bunch.

As a example, I upgraded somestuff yesterday and now I'm seeing that there's a new rc.inet1.conf file.
I execute this command: diff rc.inet1.conf rc.inet1.conf.new
and shows:

10c10
< USE_DHCP[0]="yes"
---
> USE_DHCP[0]=""

That means the only difference is that in my file there's a "yes" for dhcp
I could've also used vimdiff that will start a vim instance with splitted interface showing the differences using: vimdiff rc.inet1.conf rc.inet1.conf.new
or: vim -d rc.inet1.conf rc.inet1.conf.new

Guillermo
Approximately how many files are involved, and are they only conf files (either directly under /etc, or indirectly, like the one you mentioned: /etc/rc.d/rc.inet1.conf)? Are you able to give me an idea of the magnitude of the possible changes?
Like you, I too have
# Config information for eth0:
IPADDR[0]=""
NETMASK[0]=""
USE_DHCP[0]="yes"
DHCP_HOSTNAME[0]=""
in rc.inet1.conf.
So I guess I go back and insert the "yes". That is the concept I have difficulty with: we are talking an upgrade to a working system, and not a fresh Install, from scratch, that one needs to customize to get working. I mean, it IS working now!!!

So I guess the next question is:
How - exactly - does one know what files to diff? Is there a list (somewhere), or perhaps it is everything that has a ".new" extension. For example, does he touch /etc/samba/*.conf /etc/cups/*.conf etc., etc., not to mention my obscure friends mime.types and mime.convs (which only in a million years would a person remeber to go back and change to allow raw file printing...

Now to stand on SoapBox:

Let me add that if Linux - or at least this distribution - wants to be ready for prime-time, this kind of thing has to be fixed. For clients, no WIN user would stand for it, and for Servers,this can entail enormous re-work of working installations (and a rework which does not add any new functionality: it just gets what was once working, working again...I can appreciate that you will need to review and perhaps change these files TO GAIN ANY NEW FUNCTIONLAITY OF THE NEW RELEASE, but what used to work should still work! ). It is possible that Slackware is intended only for hobbyists and hackers - I honestly don't know - but IMHO, it is this kind of functionality, this "manageability" that separates the men from the boys, when it comes to winning market share in the home, or in the server room. I wonder if other distros do it differently???????????RHEL, or SLES? Only one way to know, I guess...
George

pkgtools (installpkg) doesn't overwrite config files by default. It creates a copy of the new config file version with a .new at the end. So when you upgrade software, if a config file already exists, the new one is created with a .new extention. That way your existing settings won't be overwritted.
Like I said, just take a look at the .new config file to see if it's too different to the one you already have. 99,99% of the time the old config file you've that's working will work, if you know your software works, just delete the .new config file.
Most of the times if the old ocnfig you've is not compatible with the new version, the program that uses it will tell you that there's an error on it, so you can take a look at the .new and see if it has changed.
I haven't seen yet (as far as I remember) that keeping a old config file will break the new release of the program. If that happens, you've the .new config file.

You know what files to diff because like I said in the other paragraph, if you upgrade a program and it has a file in /etc, it won't be replaced. The file included in the last will be installed with a .new extention.
To know which ones to diff, get into /etc and look for files with .new extention, so you can compare it with the one it doesn't have that extention.
Like: /etc/users /etc/users.new /etc/rc.d/rc.M /etc/rc.d/rc.M.new etc

It's late, I'm sorry if my explanation is a bit messing, if you've doubts I'll try to be more carefull to write next time.

Hope you get the point

Guillermo
I appreciate it.
From what you are saying, only a small number of ".new" files are introduced, and these appears to be pretty obvious ones, typically found in /etc/rc.d,. etc. i.e. "system" related config files.

It is possible that I am making more of this than is warranted, but my problem is this, simply put:

It is my understanding that after upgrading software, things that used to work - basic things, relating to the very functioning of the OS - might no longer work. Furthermore, the precise changes that need to be made to the (changed) config files are not carfefully documented, but rather, you run the system, and if something fails, you start poking around with file comparison utilities to see if the internal structure of a config file might have changed. I just wonder what the end users of the system are doing while this is going on, when something that used to work stops working .......what is happening to the business, the order taking, whatever? Of course, I understand the sysprog will have a suite of tools to test that a new release continues to function and has been upgraded correctly, but the processs - as I understand it - is not well documented, despite the many HOWTO's. Obviously , I am thinking from the point of view of a person who uses computers to run a real business, and not simply as a hobbyist.

Clearly this is not a good thing. In fact, I have never experienced it in my life, and if this ever happens (that something which used to work no longer works) , it means the upgrade has failed and needs to be backed out.

As I mentioned last nite, I am not referring to new functionality in a new release. Of course, the user may have to make changes to enable new features or new functionality.

Generally, things that need to be done before/after an upgrade are very carefully documented. Maybe I am old-fashioned, but that is what I am used to.
I guess I could accept it, if the documentaion said something like:

"Raw I/O log enablement (Linux with 2.6 kernel)

To use logs with raw I/O devices prior to DB2 Universal Database (UDB)
Version 8.2.2, it was necessary to bind a physical device to the Linux
raw character device driver with the raw utility. Starting with DB2 UDB
Version 8.2.2 (equivalent to Version 8.1 FixPak 9), on the 2.6 Linux
kernel, raw I/O for logs can be specified directly. DB2 UDB will take
advantage of a special open flag in the 2.6 kernel and enable raw I/O
for logs by default. For example, to use device partition /dev/sdb1 for
raw logs for the SAMPLE database, issue the following command:

====>db2 update db cfg for sample using newlogpath /dev/sdb1"

Or, just to press the point:
"For the IBM Developer Kit 1.4.2
Create symbolic links to libjava.so, libjvm.so, libhpi.so,
libjsig.so, libjitc.so, libxhpi.so, and libdbgmalloc.so .
You can create the symbolic links by running the following
commands as root:
cd /usr/lib
ln -fs JAVAHOME/jre/bin/libjava.so
ln -fs JAVAHOME/jre/bin/classic/libjvm.so
ln -fs JAVAHOME/jre/bin/libhpi.so
ln -fs JAVAHOME/jre/bin/libjsig.so
ln -fs JAVAHOME/jre/bin/libjitc.so
ln -fs JAVAHOME/jre/bin/libxhpi.so
ln -fs JAVAHOME/jre/bin/libdbgmalloc.so

where JAVAHOME is the base directory for the IBM Developer
Kit. "


You get the idea...........

Again, thanks, and I appreciate all your efforts to help me on this path, really, I do.


George

Yes there are only few files that change, and you can issue a simply find command to find them.

Most (if not all) critical changes in packages are documented in Slackware changelog or in the same program documentation.
The try and error example I gave is for a hobbyist as you're, but not for real bussines. Furthermore, if I had to run a critical server I wouldn't update software unless it's necessary due to some new funcionality or a bug. The new config files usually show up when upgrading the entire OS to -current or from some major version to another.

As I said, if you want to run a server, then don't upgrade if you don't really need to. Also, if there's a important change somewhere it's documented, I've never said it wasn't. The diff example I showed was a quick and dirt way of seeing the changes. And of course, if you update something and you're running a bussiness you've to test the software, so you'll know if something fails anyway

im sorry. i didnt mean to sound rude if i did. i was actually trying to be informative. just letting you know that there is newer than xfree. like i said xorg is updated nearly nightly. that was all i was getting at. as for the upgrade, most people dont do that. they simply backup and format and reinstall, cauzse you nearly cant go wrong. think about hte trouble involved. if you were goping to upgrade a few packages then i would just do that. but for the entire os, you should really consider just formatting and install fresh.

and i looked through your other post and i think it will be quite a bit harder than you think. you could make it work like windows, if you created a script that would tell it to upgradepkg bla bla bla
and run the script, then you could tell it to rename the config files. but seriously. say you spend oh 11 or 12 hours doing all this by hand. say it works. great but in about 12 minutes i couldve backed up the same system, and formatted and install 10.1 (which like i said, it has some issues) and been ready to go. and say it doesnt work. something is horrbly wrong with the steps that you do. start over. 3 days later you have a working system!! woohoo. i am just giveing my advice save yourself some time. even windows doesnt get the upgrade right most of the time.

Yes there are only few files that change, and you can issue a simply find command to find them.


gbonvehi

It's good to know that there only a few changes (".new) and they are easily found (if old data needs to be "folded" into them. I have been looking mainly at PATRICK's UPGRADE.TXT (rather than the changelog), since i was looking for the upgrade steps rather than details of the actual changes, but clearly there is a lot of info in changelog. I apologize if I indicated that you had said that important changes where not documented, because I would never have said that. I will say, however, that the changes to user configs required to get the system back and up (assuming it falls down) appear not be documented, and left to the discretion of the user.

Anyway, moving ahead, I tend to agree with you that unless there is a pressing need to upgrade (new functionality or features), stay at the current level.

I have looked carefully at the migration to 10.0 and then from 10.0 to 10.1 (which is what started this thread!!!), and the steps seems pretty much the same (UPGRADE.TXT). In fact they are identical. Clearly Patrick updates the same document each time,making minor adjustments as required. So when it is time to upgrade, I will probably do it in one step, altho' some users have found issues with 10.1

My main goal here is to have a working "sandbox" environment for IBM 's DB2 UDB, and I have exactly that in place, now (Personally, my main issue is that IBM uses RPM-based package install and S/Ware does not, but I have a workaround - rpm2tgz" utility - but that is another discussion, for another plac). The most recent DB2 FixPak (of April 2005)can exploit certain 2.6 kernel I/O-related features (I think I quoted those details above), but this is not a "standard" part of the 10.1 Release, so I may remain at 9.1 for a little while longer.
Guillermo, thanks
George

edong "im sorry. i didnt mean to sound rude if i did. i was actually trying to be informative. just letting you know that there is newer than xfree." Not at all: I didn't know that x.Org had split from XFree! It only made sense to me when I went back and red bit on X from a huge book (on RedHat, as it happens, by M. Sobell, a good book).

I take your point about re-format/install, but this is just not appropriate in my own case. I can't do that, as I have installed and customized certain system software to run under Linux (spefically, IBM's RDBMS, being DB2 UDB, and with quite a bit of pain, the product being RPM-based). If I could, that would be an "install", and not an "upgrade" of course, and I would't have the issues I outlined above.

I guess I'll go with the old saw for the time being..."if it ain't broke...etc...."(Altho between you and me, certain KDE desktop products do inexplicably abort on me, and that is what started a KDE upgrade a few weeks ago, then requiring X upgrade , then requiring a specific glibc etc., etc.....at that point I backed out KDE, with X 4.5 remaining in place....it didn't require a more recent glibc)
Thanks
George