[Pkg-zope-developers] Bug#354941: zope3-sandbox: problem seems caused by default values; suggest fixing

[Ross Boylan]

On Wed, Mar 29, 2006 at 10:12:59AM +0200, Fabio Tranchitella wrote:
> Hi Ross,
> 
> Il giorno dom, 26/03/2006 alle 12.31 -0800, Ross Boylan ha scritto:
> > Package: zope3-sandbox
> > Version: 3.2.0-4
> > Followup-For: Bug #354941
> > 
> > I ran into this too, and suggest reopening this bug for several reasons:
> >
> > 1. The problematic setting appears to be the default value.  Earlier
> > in this bug report you suggest that the submitter had set the value,
> > but if I understand the following output (the lack of a *), it means I
> > had abort from the default installation:
> 
> This is the safest behaviour possible: you are *creating* a *new* zope3
> instance called sandbox, it already exists on the filesystem but it does
> not contain data. The default choice *has to be* to abort the
> installation of the package *-sandbox, or you'll loose your old instance
> without even being warned about this. Note that if you are using ZEO,
> your instance won't contain any data and this doesn't mean that it's a
> broken instance.
> 
> By the way, the only (standard) reason to have an old sandbox instance
> is a broken installation of the package (or a manually created one).

That puzzles me.  Doesn't the installation of the  package create the
sandbox instance?  I thought that was the whole point.  So this means
that whenever you upgrade the package you have an already existing
instance.

Or maybe I'm not understanding what you mean by "old" sandbox.  I'm
interpreting it as meaning "the sandbox created by an earlier version
of zope3-sandbox."  The "new" one is the one the current version being
installed wants to create.

One of my concerns is  that if you install the package (zope3-sandbox)
and later upgrade it, without touching the defaults, it should "just
work."  I think that's hard to achieve here.  If you refuse to
upgrade, you get the problem seen here.  If you delete the old
instance, you may delete some working data, the concern you have in
mind.  You could create a new instance, e.g., sandbox2, but the
proliferation of instances doesn't seem very desirable either.

Can an existing instance be upgraded in place?

Are there any other packages in Debian that have a similar problem?
It seems a bit like migrating major versions of a database upgrade.
Installation also often has side effects like creating new users, but
I think the rule there is do nothing if the user already exists.  The
analogous rule, do nothing if a sandbox instance already exists,
effectively failes to do the upgrade, I gather.

I don't follow why ZEO vs ZODB matters.  Every instance has a
database, I think.  I also think the database would have something in
it, even if the user hadn't added anything.

> 
> > 2. Regardless of the source of the setting for
> > remove-instance-without-data, the current behavior for abort is
> > cryptic, providing little information about what is going on and none
> > about how to fix it.
> 
> I agree with you, I'll improve the error message before the abort.
> I can do this even if the bug report is closed, but if you care you
> could re-open it.

Better errors would be a big help.

> 
> > I had some trouble figuring out how to fix the problem even once I
> > knew what it was.  For example, dpkg-reconfigure did not work:
> 
> You could just `rm -fr /var/lib/zope3/instance/sandbox`.

Thanks for the tip.  That might be good to put in the error message,
or README.Debian.

> 
> > I should note that before all this I had some problems with the
> > sandbox installation, though I'm not sure if that was with Zope 3 or
> > an earlier one.
> 
> It was zope3, see above.
Well, it might have been more than one :)

> 
> > I'm also not entirely sure what the remove-instance-without-data
> > setting does, or what its implications are.  Doesn't every instance
> > have data?
> 
> No, if you are using ZEO your instance will not contain any data, just
> configurations and maybe some source packages. Nothing broken, just no
> data.

If it were possible to identify cases in which the user hadn't done
anything, I think it would be reasonable to blow them away silently.
As I've said, I'm not sure how that could be done.  Maybe something as
crude as storing the time-stamp of the database file immediately after
setup would do.  I'm not sure if there could be changes (e.g., product
installations) that didn't affect the database....

> 
> Thanks for your suggestion,
> 
Thanks for you work on the package, and for taking the time to explain
things to me.