Bug 11390 - Destructive removal of custom programs
Summary: Destructive removal of custom programs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-05-12 17:32 UTC by dgodbey
Modified: 2008-07-30 20:54 UTC (History)
2 users (show)

Fixed In Version: 1.0-4.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-12-06 20:49:13 UTC

Attachments (Terms of Use)

Description dgodbey 2000-05-12 17:32:43 UTC
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-27 01:57:49 UTC
were these packages managed by RPM?  Or just located in /usr/local?

Comment 2 dgodbey 2001-01-29 17:28:53 UTC
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 17:43:07 UTC
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-28 03:31:47 UTC
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 15:24:46 UTC

Comment 6 Michael Fulbright 2001-04-11 15:35:09 UTC
Please reopen this report if you have anything new to add.

Comment 7 dgodbey 2001-04-11 16:59:25 UTC
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 20:49:11 UTC
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 20:54:40 UTC
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.