Bug 287241 - fedora-ds-base update breaks previous installs
fedora-ds-base update breaks previous installs
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: 389-ds-base (Show other bugs)
rawhide
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Rich Megginson
Fedora Extras Quality Assurance
: screened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-12 00:42 EDT by Dennis Gilmore
Modified: 2011-04-25 19:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-22 09:27:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
upgrade11.pl - upgrade script (3.66 KB, text/plain)
2007-10-17 14:39 EDT, Rich Megginson
no flags Details

  None (edit)
Description Dennis Gilmore 2007-09-12 00:42:24 EDT
Description of problem:
the use of the %define pkgname   dirsrv macro breaks previous installs as there
is no backwards computability with the previous packaging standards.  the dirsrv
 macro needs to go immediately.  

Version-Release number of selected component (if applicable):


How reproducible: always 


Steps to Reproduce:
1. have a prior version installed with service configured
2. upgrade
3. start dirsrv  since the service name is also changed
  
Actual results:

no instances found
Expected results:

configured instances found and started

Additional info:

This was a really really bad decision.  it breaks the package completely.
Comment 1 Rich Megginson 2007-09-12 10:50:20 EDT
(In reply to comment #0)
> Description of problem:
> the use of the %define pkgname   dirsrv macro breaks previous installs as there
> is no backwards computability with the previous packaging standards.  the dirsrv
>  macro needs to go immediately.  

We put the macro in there because we didn't know if dirsrv as the package name
was going to stick, and we wanted to be able to easily change it in the future.
 Is the macro the real problem, or is the problem that we changed the pkgname
from fedora-ds to dirsrv?

> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible: always 
> 
> 
> Steps to Reproduce:
> 1. have a prior version installed with service configured
> 2. upgrade
> 3. start dirsrv  since the service name is also changed
>   
> Actual results:
> 
> no instances found
> Expected results:
> 
> configured instances found and started
> 
> Additional info:
> 
> This was a really really bad decision.  it breaks the package completely.

Yes, understood.  I suppose we could have handled this much better.  We needed
to change the pkgname asap, and didn't have a lot of time to write pre/post
scripts, migration scripts, upgrade scripts, etc. to change the names of
paths/files from fedora-ds to dirsrv.  Also, afaik, there are only a half-dozen
people actually using fedora-ds-base in Fedora right now.  Everyone else is
waiting for the console to be ready.  So as painful as this change was, it is
far less painful than it would have been had we waited any longer.
Comment 2 Dennis Gilmore 2007-09-16 23:53:53 EDT
the main problem is that you changed the package name without any 
consideration to the users.

The rest of your excuse is crap.  there is no excuse period to break users 
setups.  

I am going to revert these changes and ask that you do not redo them.
Comment 3 Rich Megginson 2007-10-17 14:39:18 EDT
Created attachment 230191 [details]
upgrade11.pl - upgrade script

This is a script which can be used to upgrade from the old style (e.g.
/etc/fedora-ds) path naming convention to the new style (e.g. /etc/dirsrv).

To use: First shutdown any fedora ds servers - service fedora-ds stop
Then, as root, run perl upgrade11.pl
Then, service dirsrv start
Comment 4 Rich Megginson 2007-10-17 14:40:25 EDT
Simo, please try the upgrade script.
Comment 5 Dennis Gilmore 2008-01-22 09:27:57 EST
Im going to close this as it is much to late to fix now

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