When upgrading from RH6.1 to RH6.2, all custom packages and their config files were erased from /usr/local. Specifically, Apache (and all config files), Acrobat4.0, and several other major packages that were installed in /usr/local were removed totally. If my Oracle 8i wasn't on a mount point, it would have been removed as well. I also had an installation of Active Perl in /bin that was also removed. I was under the impression that upgrading a system didn't remove or impact anything except the specific files included in the package. And, if other package versions were installed in 'non-standard' locations, they would be left alone. Fortunately, I have install RPM's of most of the stuff that was removed as well as download versions of the other packages. However, the specially written code in /usr/local/bin that the developer's did not have a backup for is gone. You have made a great product that works like a dream, but this kind of problem will impact the newbie and cause unfavorable press. We have enough to handle without having to deal with this kind of problem, too.
were these packages managed by RPM? Or just located in /usr/local?
The programs were developed by local programmers and were stored in /usr/local/bin with support libraries in /usr/local/lib. None of the files deleted were managed by RPM. It seemed that all file data in /usr/local/* was deleted even though the process used was an upgrade and not an install. Also, the file systems were not changed or reformated at the time of the upgrade.
I've never heard of a problem like this one. The upgrade process doesn't touch /usr/local at all. Could you attach your /tmp/upgrade.log?
No. I no longer have access to that system. It was strange, though. I had Active Perl loaded in /bin that was removed, along with other packages that weren't in the RedHat mix. I guess, though, since 7.0 was released, that the problem is now masked and unduplicate-able. It could have been a fluke, but without the logs it's impossible to prove or find out what actually happened. I still have the release CD's in hand and I guess I could play around with it. I have rel 5.2, 6.0, 6.1, 6.2 and 7.0 onhand so I'll see if I can duplicate the hit. I'll let you know in a week or two.
Thanks.
Please reopen this report if you have anything new to add.
I have been unable to duplicate the failure on my current mix of systems (Compac EN, A550, HP Vectra VE, HP Kayak XA, and others both single CPU and SMP). I have attempted to duplicate the full range of upgrades including massive steps in versions (5.2 directly 6.2) and haven't experienced the same problem. For the most part, the content of /usr/local/* remained untouched. The only problems I encountered were expected (system resource types of things like memory, BIOS, etc.). I had a couple of driver problems with an old DEC PC, but that was easily taken care of with a BIOS update. The process I followed was basically this: Started with a "new" install of 5.2 and followed that with "normal" release step updates up to 6.2. I installed a fresh copy of Active Perl at each release level and ran a few application tests and configurations with XFree86 and X. I let each level run for a minimum of 10 days to insure logging and kernel processes were fully functional before moving to the next release level of RH. Fortunately, since I now work for BMC Software as a Staff QA Rep, I have extensive access to platforms and systems. Talk about a playground! WHEE! The end result is, with all the tools and systems at hand, I was totally unable to get an installation failure of the type I originally reported. To say I had a ball doing this would be a massive understatement. I even had IBM 5L involved as a side issue test and managed to get IBM involved in some things I found there. I was on a major roll! :) Thanks for the excuse to go play!
libxcb-1.0-4.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
libxcb-1.1-1.fc8.i386.rpm breaks what libxcb-1.0-4.fc8 fixed. I don't believe this was the right bug for that package, though, although for some reason the original release notes for libxcb-1.0-4.fc8 reported this bug number. That would appear to be a mistake.