[Pkg-corba-devel] omniorb4 package name change

[Floris Bruynooghe]

On Fri, May 16, 2008 at 11:40:47PM +0100, Floris Bruynooghe wrote:
> I've thought a bit more about the omniNames DB problem...
> 
> On Sun, May 11, 2008 at 04:19:31PM +0100, Floris Bruynooghe wrote:
> > On Sat, May 10, 2008 at 05:27:37PM +0200, Thomas Girard wrote:
> > >  * init.d scripts have to handle this transition for omniorb-nameserver;
> > >    i.e. handle the /var/lib/omniorb4 -> /var/lib/omniorb and the
> > >    /var/log/omniorb4-nameserver.log -> /var/log/omniorb-nameserver.log
> > >    move.
> > 
> > Oops, overlooked that.  Last time we moved the DB in the preinst (and
> > postrm for rollback) script which seems a good place to do this I
> > think.  Now there are three options:
> > 
> > * Do this in the preinst of omniorb-nameserver.  This would mean we
> >   have no idea which version of omniorb4-nameserver (if any) was
> >   installed before (etch or testing) and the best we can do is check
> >   that DB file in both locations and move the files when they're
> >   there.  The problem is for the rollback (abort-install to postrm) as
> >   we don't know where to rolback too.
> 
> This is rubbish as the rolback doesn't work as it should.
> 
> 
> > * Do this in the preinst of the transitional package of
> >   omniorb4-nameserver.  We would know the previous version installed
> >   and can do a slightly more secure moving of the DB (i.e. support
> >   rollback properly).  The downside is that a removal of
> >   omniorb4-nameserver followed by an install of omniorb-nameserver
> >   would not move the database.
> 
> I was favouring this and actually started writing it.  But it's also
> rubbish as there is no sane way to make sure that the preinst script
> of omniorb4-nameserver is run before the postinst of
> omniorb-nameserver (Pre-Depends is not sane I think).
> 
> > * Do this in the postinst of omniorb-nameserver.  Same as the first
> >   option, just check where the DB could be, if any, and move it
> >   unconditionally.  The rollback problem here doesn't exist anymore as
> >   there's none to support.  Only issue left here is that we're not
> >   really sure we moved an omniNames DB file since we're not sure we
> >   had it installed and thus anyone could have created a file there
> >   with that name without anyone complaining.
> 
> Which means I'm going with this option...
> 
> Again, I could be wrong.  Feel free to disagree with me.

Ok, I'm stuck again.  I tested the upgrade from testing last week but
only got round to testing the upgrade from etch today.  And the etch
postrm is called before the new postinst.

Sadly the old postrm decides to clean up the database whenever it is
run instead of just for purge.  This means it simply wipes away the
database before we can copy it.  This brings us back to doing the
migration in the transitional package, which has the pre-depends
problem.

Not sure what to do now, again.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org