This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 11390 - Destructive removal of custom programs
Destructive removal of custom programs
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-12 13:32 EDT by dgodbey
Modified: 2008-07-30 16:54 EDT (History)
2 users (show)

See Also:
Fixed In Version: 1.0-4.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-06 15:49:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description dgodbey 2000-05-12 13:32:43 EDT
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.
Comment 1 Matt Wilson 2001-01-26 20:57:49 EST
were these packages managed by RPM?  Or just located in /usr/local?
Comment 2 dgodbey 2001-01-29 12:28:53 EST
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.
Comment 3 Matt Wilson 2001-01-29 12:43:07 EST
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?
Comment 4 dgodbey 2001-02-27 22:31:47 EST
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.
Comment 5 Michael Fulbright 2001-02-28 10:24:46 EST
Thanks.
Comment 6 Michael Fulbright 2001-04-11 11:35:09 EDT
Please reopen this report if you have anything new to add.
Comment 7 dgodbey 2001-04-11 12:59:25 EDT
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!
Comment 8 Fedora Update System 2007-12-06 15:49:11 EST
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.
Comment 9 jdavidb 2008-07-30 16:54:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.