Re: 2 issues about zope-* packages
* Luca - De Whiskey's - De Vitis <firstname.lastname@example.org> [020326 01:27]:
> The second issue is abuot the zope restart for each zope modules installed:
> refer to bug #134516.
> I think that we can do something better using apt.conf option. 
> My idea is that the prompt should be:
> Would you like to restart zope:
> (1) After module package unpacking.
> (2) Once, at the end of the installation process.
> (3) Manually.
> If option (2) is selected, zope modules packages may touch a file  on
> postinst to state that user wants zope to be restarted only once at the end;
> zope, that installed an apt configuration file , may uses the apt option
>  to restart itself checking for packages file .
> I'd appreciate any opinion, hint and so on.
Just as a sidenote:
First of all, mea culpa for being a bad maintainer of the zope package
in the last few months. Part of it was due to the Python transition
(though doko deserves a lot of credits for most of the work), part of it
was due to real world issues. Thankfully, some of these real world
issues gave me some ideas about what is broken in the design of the Zope
I already told a few of you in private emails about my plans for
refactoring the Zope package.
One issue is that I'd like to split the sample Zope instance
(Data.fs.in) off from the Zope framework; i.e. installing the "zope"
package should *not* set up and configure any Zope server instance, but
only install the framework. Instead, there would be a new package (e.g.
"zope-simple" or "zope-example") which would install and (deb)configure
a single sample Zope instance.
That should make it much easier to setup more complicated scenarios like
a server running multiple Zope instances or ZEO. Furthermore, it would
help the autobuilders with build-depends (although I'm thinking about
splitting off a zope-dev package with headers at al).
If all works well, I might have a working prototype of this NG Zope
packages at the end of the next week.
I would appreciate comments regarding this redesign.
Regarding the restart issue: What you suggest, Luca, sounds really good
to me (I tried to achieve something similiar by hacking with debconf:
but your attempt sounds more relaxed).
A remaining problem are .zexp products. I don't see any solution at all
for packaging them so that they get automatically and safely upgraded
(I could even say: I don't see any reason for packaging them ;-).
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org