[Pkg-corba-devel] omniorb4 package name change

[Floris Bruynooghe]

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.

Regards
Floris


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