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
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.
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.