What do we want in the way of Zope binary distributions?
Hi, With the new Zope 2.7 install and configuration stuff (currently on the Zope trunk), ZC needs to redo its mechanisms for Zope binary distribution. Currently, ZC distributes binaries for Win32, Linux, and Solaris on Zope.org. The Linux and Solaris distributions are in the form of a tarball containing binaries. The Win32 distribution contains an executable installer generated by WISE. I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc. It's getting a bit scary to try to distribute a "generic" Linux binary release (who knows what's different about each?), and we really don't have the resources to do a functional test of the binary release on every Linux platform. Additionally, most Linux distributions typically come with all the required tools to compile Zope from source, and compiling Zope from source is now a matter of 'configure; make; make install'. If people don't want to do this, they can install the RPM or their distribution's repackaging of Zope (ala Debian). I also propose we drop the Solaris binary distribution in favor of providing instructions to Solaris folks about how to compile and install the source package. This might be the most contentious proposal: I really have no idea how many people use the Solaris binary distro. The Win32 binary release should likely stay much like it is. I'm not sure about the "upgrade" release packages. Does anybody use these? Comments? - C
On Wednesday 16 April 2003 3:25 pm, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
Comments?
I would appreciate a pgp signature for official releases, source and binary. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On Wed, 2003-04-16 at 07:37, Toby Dickenson wrote:
On Wednesday 16 April 2003 3:25 pm, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
I am... putting some effort toward keeping the Zope ebuild current would be really helpful. Last time I checked, it's only current to 2.6.0. Don't know much about making ebuilds, but I've been meaning to get good at it for a few months now... this would be as good a reason as any. I'm willing to help, but probably not the best person to lead. Dylan
FWIW, the installation and configuration process for 2.7 will be different than others in the 2.X series, so you may end up maintaining two significantly different build generators if you intend on "signing up" to them for both 2.6 and 2.7/8/9, etc. Just a heads-up. On Wed, 2003-04-16 at 12:37, Dylan Reinhardt wrote:
On Wed, 2003-04-16 at 07:37, Toby Dickenson wrote:
On Wednesday 16 April 2003 3:25 pm, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
I am... putting some effort toward keeping the Zope ebuild current would be really helpful. Last time I checked, it's only current to 2.6.0.
Don't know much about making ebuilds, but I've been meaning to get good at it for a few months now... this would be as good a reason as any. I'm willing to help, but probably not the best person to lead.
Dylan
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I like the linux tarball a lot. With it you can get a Zope installation running pretty much anywhere on the filesystem with great speed and little hassle. (Not having to think about the system Python version, for instance.) I may have strange use patterns, but I do that often enough to notice. I won't cry over it going away if the new source install is as simple as described. But I sure find it a handy thing to have around (and have never had any problems with it on any or the various and often strange environments I've used it on.) --jcc
Hi, Thanks for the input. Does anyone else have a desire to get Linux binaries in a tarball? On Wed, 2003-04-16 at 16:32, J Cameron Cooper wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I like the linux tarball a lot. With it you can get a Zope installation running pretty much anywhere on the filesystem with great speed and little hassle. (Not having to think about the system Python version, for instance.) I may have strange use patterns, but I do that often enough to notice.
I won't cry over it going away if the new source install is as simple as described. But I sure find it a handy thing to have around (and have never had any problems with it on any or the various and often strange environments I've used it on.)
--jcc
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Greetings, I'm trying to get up-to-speed on TextIndexNG and am doing well with simple queries. However, if I quote search text, the search returns with a KeyError indicating it can't find the catalog. The same error shows up when I try to use either of the QueryParsers tests on "Test" tab of the index -- even for the most trivial or empty queries. I'll bet I missed something in the set up, but I can't figure out what. Anyone run into this? The traceback, in case it's helpful: Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: parser Module <string>, line 0, in ? Module Products.TextIndexNG.TextIndexNG, line 818, in testTextIndexNG Module Products.TextIndexNG.TextIndexNG, line 843, in _getCatalog Module OFS.Traversable, line 120, in unrestrictedTraverse - __traceback_info__: ([], 'Catalog') Module OFS.Application, line 108, in __bobo_traverse__ KeyError: Catalog -- ______________________________________________________ Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only. -aj --On Mittwoch, 16. April 2003 15:08 Uhr -0700 Steve McMahon <steve@reidmcmahon.com> wrote:
Greetings,
I'm trying to get up-to-speed on TextIndexNG and am doing well with simple queries. However, if I quote search text, the search returns with a KeyError indicating it can't find the catalog. The same error shows up when I try to use either of the QueryParsers tests on "Test" tab of the index -- even for the most trivial or empty queries.
I'll bet I missed something in the set up, but I can't figure out what. Anyone run into this?
The traceback, in case it's helpful: Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: parser Module <string>, line 0, in ? Module Products.TextIndexNG.TextIndexNG, line 818, in testTextIndexNG Module Products.TextIndexNG.TextIndexNG, line 843, in _getCatalog Module OFS.Traversable, line 120, in unrestrictedTraverse - __traceback_info__: ([], 'Catalog') Module OFS.Application, line 108, in __bobo_traverse__ KeyError: Catalog
-- ______________________________________________________
Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Hi Andreas, Thanks for your great work on TextIndexNG! You're right about the problem with the 'Test' tab being cosmetic. However, I'm running into the same problem (basically identical traceback) with my own search methods whenever I do a phrase (with quotes) or near search. Thanks, Steve Andreas Jung wrote:
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only.
-aj
--On Mittwoch, 16. April 2003 15:08 Uhr -0700 Steve McMahon <steve@reidmcmahon.com> wrote:
Greetings,
I'm trying to get up-to-speed on TextIndexNG and am doing well with simple queries. However, if I quote search text, the search returns with a KeyError indicating it can't find the catalog. The same error shows up when I try to use either of the QueryParsers tests on "Test" tab of the index -- even for the most trivial or empty queries.
I'll bet I missed something in the set up, but I can't figure out what. Anyone run into this?
The traceback, in case it's helpful: Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: parser Module <string>, line 0, in ? Module Products.TextIndexNG.TextIndexNG, line 818, in testTextIndexNG Module Products.TextIndexNG.TextIndexNG, line 843, in _getCatalog Module OFS.Traversable, line 120, in unrestrictedTraverse - __traceback_info__: ([], 'Catalog') Module OFS.Application, line 108, in __bobo_traverse__ KeyError: Catalog
-- ______________________________________________________
Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- ______________________________________________________ Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
What Zope version are you running? There were some fixes for 2.6 and 2.7 with acquisition wrappers passed to the constructor of indexes. In fact I have not seen this problem with TextIndexNG 1.09 and Zope 2.6/2.7 during the last time (it is running in this combination in production on several sites). -aj --On Donnerstag, 17. April 2003 9:00 Uhr -0700 Steve McMahon <steve@reidmcmahon.com> wrote:
Hi Andreas,
Thanks for your great work on TextIndexNG!
You're right about the problem with the 'Test' tab being cosmetic. However, I'm running into the same problem (basically identical traceback) with my own search methods whenever I do a phrase (with quotes) or near search.
Thanks, Steve
Andreas Jung wrote:
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only.
-aj
--On Mittwoch, 16. April 2003 15:08 Uhr -0700 Steve McMahon <steve@reidmcmahon.com> wrote:
Greetings,
I'm trying to get up-to-speed on TextIndexNG and am doing well with simple queries. However, if I quote search text, the search returns with a KeyError indicating it can't find the catalog. The same error shows up when I try to use either of the QueryParsers tests on "Test" tab of the index -- even for the most trivial or empty queries.
I'll bet I missed something in the set up, but I can't figure out what. Anyone run into this?
The traceback, in case it's helpful: Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: parser Module <string>, line 0, in ? Module Products.TextIndexNG.TextIndexNG, line 818, in testTextIndexNG Module Products.TextIndexNG.TextIndexNG, line 843, in _getCatalog Module OFS.Traversable, line 120, in unrestrictedTraverse - __traceback_info__: ([], 'Catalog') Module OFS.Application, line 108, in __bobo_traverse__ KeyError: Catalog
-- ______________________________________________________
Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- ______________________________________________________
Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Andreas Jung wrote:
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only.
Just FYI, I have installed TextIndexNG (which is very nice) in a basically clean zope and have exactly the same problem. The only "speciality" is that this is in a PortalCatalog, not a ZCatalog. The error occurs in this line: self._v_catalog = self.getPhysicalRoot().unrestrictedTraverse(self.catalog_path) and an external method returning Indexes['content_ng'].catalog_path for an textindexNG gives me just 'portal_catalog', which is obviously not the real physical path to the catalog. HTH, oliver
--On Donnerstag, 17. April 2003 18:20 Uhr +0200 Oliver Bleutgen <myzope@gmx.net> wrote:
Andreas Jung wrote:
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only.
Just FYI, I have installed TextIndexNG (which is very nice) in a basically clean zope and have exactly the same problem. The only "speciality" is that this is in a PortalCatalog, not a ZCatalog.
The error occurs in this line: self._v_catalog = self.getPhysicalRoot().unrestrictedTraverse(self.catalog_path)
and an external method returning Indexes['content_ng'].catalog_path for an textindexNG
gives me just 'portal_catalog', which is obviously not the real physical path to the catalog.
This indicates that the caller (the ZCatalog instance) returns a wrong value for getPhyisicalPath(). In case of a CMF/Plonesite the result should /site/portal_catalog. I pretty sure that the the caller is an Acquisition wrapper that returns the wrong value. Maybe it might help to modify the getPhysicalPath() call in __init__() so that the unwrapped object is called instead of the wrapper (using aq_base() & friends): -aj
As a workaround you should try the following: TextIndexNG.py around line 840: replace self._v_catalog = self.getPhysicalRoot()..... with self._v_catalog = getattr(self, self.catalog_path) This should work in case when caller.getPhysicalPath() returns a wrong result. In this case be use acquisition instead of traversal to get the catalog instance. -aj --On Donnerstag, 17. April 2003 18:20 Uhr +0200 Oliver Bleutgen <myzope@gmx.net> wrote:
Andreas Jung wrote:
This problem *should* be fixed in 1.09. But you need to recreate the index. Btw. this problem is only of cosmetic nature since the core functionality remains untouched. This method is for testing purposes only.
Just FYI, I have installed TextIndexNG (which is very nice) in a basically clean zope and have exactly the same problem. The only "speciality" is that this is in a PortalCatalog, not a ZCatalog.
The error occurs in this line: self._v_catalog = self.getPhysicalRoot().unrestrictedTraverse(self.catalog_path)
and an external method returning Indexes['content_ng'].catalog_path for an textindexNG
gives me just 'portal_catalog', which is obviously not the real physical path to the catalog.
HTH, oliver
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Another solution might be: self._v_catalog = self.aq_parent.aq_parent -aj --On Freitag, 18. April 2003 11:09 Uhr +0200 Andreas Jung <andreas@andreas-jung.com> wrote:
As a workaround you should try the following:
TextIndexNG.py around line 840:
replace self._v_catalog = self.getPhysicalRoot()..... with
self._v_catalog = getattr(self, self.catalog_path)
This should work in case when caller.getPhysicalPath() returns a wrong result. In this case be use acquisition instead of traversal to get the catalog instance.
-aj
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
Here, here!! Zope-2.6.1 install on gentoo was the smoothest Zope install I've ever done. Keep up the good work!
Apologies if this is a little late... On Wed, 2003-04-16 at 09:37, Toby Dickenson wrote:
On Wednesday 16 April 2003 3:25 pm, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
We're using a lot of gentoo internally here - up-to-date gentoo ebuilds would be *greatly* appreciated.
Comments?
Along the lines of gentoo ebuilds - if you're going to provide RPMs, could you provide the Source RPM as well? That makes the RPM more widely usable... -- Nathan 'Nato' Uno Zope Developer Hostway Corporation http://www.hostway.com/
I think we decided that there will be no ZC-distributed UNIX binary distribution nor a source distribution packaged any other way but as a tar.gz... but if other folks want to package them as they like, they're free to do so. On Tue, 2003-04-22 at 16:09, Nathan 'Nato' Uno wrote:
Apologies if this is a little late...
On Wed, 2003-04-16 at 09:37, Toby Dickenson wrote:
On Wednesday 16 April 2003 3:25 pm, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
We're using a lot of gentoo internally here - up-to-date gentoo ebuilds would be *greatly* appreciated.
Comments?
Along the lines of gentoo ebuilds - if you're going to provide RPMs, could you provide the Source RPM as well? That makes the RPM more widely usable...
-- Nathan 'Nato' Uno Zope Developer Hostway Corporation http://www.hostway.com/
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Hi Nathan & all
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
We're also installing Zope on Gentoo all over the place. So far, I've only played with the ebuilds on my laptop. For "real work" we have always installed from Zope source, but it would be great if Gentoo integrated Zope so that we could use it to manage instances and products. Gentoo has already started along the route, with scripts like zprod-manager, but I'm not comfortable that it's understandable and flexible enough yet .. -- Jean Jordaan http://www.upfrontsystems.co.za
On Wed, 2003-04-23 at 01:01, Jean Jordaan wrote:
it would be great if Gentoo integrated Zope so that we could use it to manage instances and products.
Have you tried the latest 2.6.1 ebuild? It's only a week or two old and is well worth a look if you haven't emerged it yet. Dylan
Hi Nathan & all
I may volunteer for updating the gentoo ebuild.... Anyone else using gentoo linux here?
We're also installing Zope on Gentoo all over the place. So far, I've only played with the ebuilds on my laptop. For "real work" we have always installed from Zope source, but it would be great if Gentoo integrated Zope so that we could use it to manage instances and products. Gentoo has already started along the route, with scripts like zprod-manager, but I'm not comfortable that it's understandable and flexible enough yet .. -- Jean Jordaan http://www.upfrontsystems.co.za
Chris McDonough wrote at 2003-4-16 10:25 -0400:
... I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake,
Personnaly, I do not like RPM. It often wants to install at places where I do not want the installation. I much prefer "tar" balls (but I use the source distribution anyway). Dieter
On Wed, 2003-04-16 at 15:32, Dieter Maurer wrote:
Chris McDonough wrote at 2003-4-16 10:25 -0400:
... I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake,
Personnaly, I do not like RPM.
It often wants to install at places where I do not want the installation.
I much prefer "tar" balls (but I use the source distribution anyway).
Hi Dieter, Yup. I'd rather install from source too. I'm interested in hearing from people who you think we should continue to create binary tarball distributions for Linux. It doesn't sound like you use the binary Zope distro for Linux, or do you? - C
Hi Dieter,
Yup. I'd rather install from source too.
I'm interested in hearing from people who you think we should continue to create binary tarball distributions for Linux. It doesn't sound like you use the binary Zope distro for Linux, or do you?
- C
I have long advocated that zope.org drop binaries for linux. I think that packaging is too political and too tricky for zope.org to be doing. In particular, proper FHS support seems to be tricky. I think that virtually every distribution packages Zope now. If people want to use a binary version, then it seems more appropriate that they use the distribution's, and that the distribution take the heat when it fails to work. I would recommend that zope.org publicize links to distribution's versions, probably with a "outside our control, quality problems should be taken up with the distribution" disclaimer. In particular, the current binary on zope.org, with its non-FHS, non-anything standard path scheme, in my opinion, causes more grief than it is worth. Jim Penny Windows is another story: I try to stay as far away as possible, but I suspect that the windows binary is a boon to those who want to use that platform.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Thu, 17 Apr 2003 12:25 am, Chris McDonough wrote:
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
I'm all for this! The RPM would install everything into /usr/lib/zope-2.7/* except the bin directory, which it'd install in /usr/bin. That'd work on any RPM platform, and thanks to the mk* scripts, the actual installation of a zope instance is soooo much easier now. Previously the RPM had to worry about creating stuff in /var and /lib and all that mess. Now that problem's just gone away :) Richard
Richard Jones wrote I'm all for this! The RPM would install everything into /usr/lib/zope-2.7/* except the bin directory, which it'd install in /usr/bin.
Could it not be /usr/bin, please? /usr/bin is a sewer on linux distributions, and trying to find the damn zope scripts there will be such a pain. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Thu, 17 Apr 2003 03:57 pm, Anthony Baxter wrote:
Richard Jones wrote
I'm all for this! The RPM would install everything into /usr/lib/zope-2.7/* except the bin directory, which it'd install in /usr/bin.
Could it not be /usr/bin, please? /usr/bin is a sewer on linux distributions, and trying to find the damn zope scripts there will be such a pain.
It'll end up in the user's path, that's all. It'll go wherever they set the install prefix to. Is that OK? Richard
I might be tempted to just dump the software home in /opt/Zope-X.X (or somewhere else suitable) and not bother with putting the mk* scripts into the a directory on the PATH (just keep them in sw_home/bin). Then again, it would be kinda nice to just type: $ sudo rpm -Uvh Zope-2.X.X.rpm $ mkzopeinstance ~/instance But going forward we'd have the problem of multiple Zope versions on the same machine.. to which one would "mkzopeinstance" belong, or would we name one "mkzopeinstance27" and the other "mkzopeinstance28"? Like I said, I might be tempted to just punt and leave the binaries in the software home bin dir. On Thu, 2003-04-17 at 01:57, Anthony Baxter wrote:
Richard Jones wrote I'm all for this! The RPM would install everything into /usr/lib/zope-2.7/* except the bin directory, which it'd install in /usr/bin.
Could it not be /usr/bin, please? /usr/bin is a sewer on linux distributions, and trying to find the damn zope scripts there will be such a pain.
Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris McDonough writes:
I might be tempted to just dump the software home in /opt/Zope-X.X (or somewhere else suitable) and not bother with putting the mk* scripts into the a directory on the PATH (just keep them in sw_home/bin). Then again, it would be kinda nice to just type:
$ sudo rpm -Uvh Zope-2.X.X.rpm $ mkzopeinstance ~/instance
Perhaps it would be, but the multi-version issue is real. I think the right thing is to let people deal with that on a per-site basis; some people will want to extend their PATH to include the Zope installation they want to use, and others will want to always be explicit. Infecting a "standard" bin directory isn't something we should do; if a site wants that, they can add symlinks there on their own. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Chris McDonough wrote: [snip]
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
+1 Additionally I think providing source RPMs might be a good idea; they usually work on a broader range of RPM based distributions
I'm not sure about the "upgrade" release packages. Does anybody use these?
Never have... - peter.
Just some random thoughts from someone who doesn't use the binaries anyway, but helped people who do: LFS support on linux would be nice (if not obligatory when using Data.fs). How are you going to cope with the fact that the stock python from the distribution maker might not be the "recommended/supported" version for the zope? I guess nobody can guarantee that even for the next two version of RH linux. So, are you going to include a python with the zope RPM? While I'm no rpm expert, I know there are the options --relocate and --prefix, which allow to modify where the package is installed. The package must somehow support this. So, an optimal installation package would IMO consist of two rellocatable rpms, python (if needed because the distribution doesn't have the right one) and zope. cheers, oliver
On Thu, 2003-04-17 at 06:46, Oliver Bleutgen wrote:
Just some random thoughts from someone who doesn't use the binaries anyway, but helped people who do:
LFS support on linux would be nice (if not obligatory when using Data.fs).
The Python 2.2.2 that "ships" with RH 7.3+ is indeed LFS enabled.
How are you going to cope with the fact that the stock python from the distribution maker might not be the "recommended/supported" version for the zope? I guess nobody can guarantee that even for the next two version of RH linux.
We lucked out a bit here because Red Hat uses Python for a lot of their tools. So we're almost guaranteed that Python 2.2.2 (the target version for Zope 2.7) will be installed on any recent Red Hat system. I think it's pretty safe to assume that Python 2.3+ will also be available in RPM format, so if we come to depend on later Python versions, we can just depend on the RPM of that version. I had a problem with Red Hat's Python 2.2.0 distro because they failed to include the compiler package along with the release, but this has been fixed in their 2.2.2 package.
So, are you going to include a python with the zope RPM?
No. The RPM will just depend on (require) the proper version of the system Python. I have a spec file stubbed out at http://cvs.zope.org/Zope/inst/Attic/Zope.spec.in?rev=1.1.2.8&only_with_tag=c... It needs to change, as it was written before lots of the rest of the installer changes. It was also written before 2.2.2 was available from Red Hat in an RPM format, but AFAIK, the latest Python that Red Hat now ships is 2.2.2, with the package name python2-2.2.2-11.7.3.
While I'm no rpm expert, I know there are the options --relocate and --prefix, which allow to modify where the package is installed. The package must somehow support this.
It would be nice to have, but IMHO most people who would install from an RPM wouldn't know how to relocate the package anyway, don't you think? I I think the idea is to give folks who aren't comfortable with source releases an easy way to get going, but I'm not sure how many people would use RPM to do version control like this. Additionally, many instance homes can share a single software home and instance homes can be installed anywhere. The installation of an instance home will however not be managed via RPM.
So, an optimal installation package would IMO consist of two rellocatable rpms, python (if needed because the distribution doesn't have the right one) and zope.
Since we will only target recent Red Hat releases, we know that it has a suitable Python RPM, and we will depend on it. Other folks can use the source distro or package up their own RPMs of Zope and/or Python for their favorite RPM-based distro. Does all of this make sense? - C
Chris McDonough wrote:
On Thu, 2003-04-17 at 06:46, Oliver Bleutgen wrote:
How are you going to cope with the fact that the stock python from the distribution maker might not be the "recommended/supported" version for the zope? I guess nobody can guarantee that even for the next two version of RH linux.
We lucked out a bit here because Red Hat uses Python for a lot of their tools. So we're almost guaranteed that Python 2.2.2 (the target version for Zope 2.7) will be installed on any recent Red Hat system. I think it's pretty safe to assume that Python 2.3+ will also be available in RPM format, so if we come to depend on later Python versions, we can just depend on the RPM of that version.
I thought more of the situation where the stock python from the distribution is about 3 years younger the the version of python needed for the current zope. But that can never happen, right? ;) I can just relate to SuSE, and they had, AFAIR, never a specific python 2.1.3 rpm, python 2.1.3 was just included in the zope rpm. The result from something like that is that people get confused when they want to install python packages needed for a zope product they want. They often end up installing them for the wrong python.
No. The RPM will just depend on (require) the proper version of the system Python.
I have a spec file stubbed out at http://cvs.zope.org/Zope/inst/Attic/Zope.spec.in?rev=1.1.2.8&only_with_tag=c...
Which illustrates my point perfectly: """ # python2.2 packages from RedHat don't have 'compiler' package, but #2.2.1 packages do, so we require 2.2.1, although 2.2.1 has bugs #itself that cause Zope to crash. We should require 2.2.2 here, but #it hasnt yet been packaged. """
While I'm no rpm expert, I know there are the options --relocate and --prefix, which allow to modify where the package is installed. The package must somehow support this.
It would be nice to have, but IMHO most people who would install from an RPM wouldn't know how to relocate the package anyway, don't you think? I I think the idea is to give folks who aren't comfortable with source releases an easy way to get going, but I'm not sure how many people would use RPM to do version control like this. Additionally, many instance homes can share a single software home and instance homes can be installed anywhere. The installation of an instance home will however not be managed via RPM.
Fair point. But the more I think about it the more I get the same opinion as Jim Penny. I would consider not offering any binaries on zope.org, at least not rpms which give a false impression of "robustness". If people get the rpm to install, they expect the software to run flawlessly, and _will_ use it for production. Not a good idea in the constellation you are descibing in your spec comments. ZC will never be able to offer the same testing as a distribution does (or at least) should, esp. concerning side possible side effects with other system components. Apart from the general problem that Zope is very dependend (at the moment) on running on the right version of python, there's more to it. When you go the rpm route, you are caught in the distribution business. One example from SuSe 8.1, which has a seperate rpm package for the mysql DA:
rpm -qpR zope-mysql-2.0.8-345.i586.rpm zope python-mysql rpmlib(PayloadIsBzip2) <= 3.0.5-1
So, if a user installed your rpm, he will be able (AFAIK) to install the stock zope-mysql DA. But what happens if this doesn't work? Are you sure you have the resources to untagle the mess distributions will be able to cause, when they begin to offer not one, but 20 extra rpms for certain zope products? But if all you want to do is to give the beginner an easy starting point (which you seem to imply in your last paragraph), why not just stay with the bin.tgz? But you really don't need to convince me, since I'm not a user of the binaries, I just want to give an other persective. cheers, oliver
I can just relate to SuSE, and they had, AFAIR, never a specific python 2.1.3 rpm, python 2.1.3 was just included in the zope rpm. The result from something like that is that people get confused when they want to install python packages needed for a zope product they want. They often end up installing them for the wrong python.
Right. Which is why I'd rather not package a separate Python for Zope. And also why I'd want to "guarantee" that ZC-produced RPMs would run on some version of Red Hat and not guarantee anything further. That's not to say they won't run on other platforms, just that we can't promise they will.
No. The RPM will just depend on (require) the proper version of the system Python.
I have a spec file stubbed out at
http://cvs.zope.org/Zope/inst/Attic/Zope.spec.in?rev=1.1.2.8&only_with _tag=chrism-install-branch&content-type=text/vnd.viewcvs-markup
Which illustrates my point perfectly:
""" # python2.2 packages from RedHat don't have 'compiler' package, but #2.2.1 packages do, so we require 2.2.1, although 2.2.1 has bugs #itself that cause Zope to crash. We should require 2.2.2 here, but #it hasnt yet been packaged. """
That particular bug has been fixed by Red Hat and Python 2.2.2 is now the stock Python 2 on RH 7.3+ (with compiler package and LFS). This matches our current requirements perfectly. Your point is taken, however, that this will not always be the case.
But the more I think about it the more I get the same opinion as Jim Penny. I would consider not offering any binaries on zope.org, at least not rpms which give a false impression of "robustness". If people get the rpm to install, they expect the software to run flawlessly, and _will_ use it for production. Not a good idea in the constellation you are descibing in your spec comments.
Yup.
ZC will never be able to offer the same testing as a distribution does (or at least) should, esp. concerning side possible side effects with other system components.
I'm not sure anybody can, at least without a top-down binary distribution model like Debian's, but I agree. <snip examples>
So, if a user installed your rpm, he will be able (AFAIK) to install the stock zope-mysql DA. But what happens if this doesn't work? Are you sure you have the resources to untagle the mess distributions will be able to cause, when they begin to offer not one, but 20 extra rpms for certain zope products?
No, you're right, I hadn't thought about it past actually creating the Zope RPM itself.
But if all you want to do is to give the beginner an easy starting point (which you seem to imply in your last paragraph), why not just stay with the bin.tgz?
Because we make the implicit promise that it will work on every Linux distro, regardless of libc version, availability of large file support on the platform, etc. We can't test on all of these platforms (the same "robustness" problem you mention above). The desire to package an RPM instead of a tarball is really a desire to make an insane situation into a sane one by limiting the platforms on which we guarantee the software to work (in this case, Red Hat 7.3+). But I understand that this is a politics
But you really don't need to convince me, since I'm not a user of the binaries, I just want to give an other persective.
Fair enough, and thanks. Maybe we should forego ZC-produced RPM distros. I dont have the time to deal with the politics, let alone the technology issues you raise. Let the distribution makers deal with it. ;-) A middle-ground alternative would be to package SRPMS but not binaries. I'm not sure what real goal this would serve, however. - C
In article <1050503118.1421.48.camel@james> you write:
Hi,
With the new Zope 2.7 install and configuration stuff (currently on the Zope trunk), ZC needs to redo its mechanisms for Zope binary distribution. Currently, ZC distributes binaries for Win32, Linux, and Solaris on Zope.org. The Linux and Solaris distributions are in the form of a tarball containing binaries. The Win32 distribution contains an executable installer generated by WISE.
Ok if you dig into the build process, could you please ensure that all necessary .so files are built and shipped? See http://collector.zope.org/Zope/678
I'd like to propose that ZC drops the "generic" Linux binary distribution in favor of an RPM distribution that would be "guaranteed" to run on the latest Red Hat release or the one before it, but might also work on Mandrake, etc.
Well I like to use "pristine" binary builds from ZC to get reproducible environment, but having an RPM will mean that it'll only allow me to install it in one place, so only one Zope instance. Well ok, I know lots of ways to get what I need (rpm2cpio for one), but it will complicate my life a bit. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Ok if you dig into the build process, could you please ensure that all necessary .so files are built and shipped? See http://collector.zope.org/Zope/678
Sure, thanks. FWIW, I am trying at this very moment to understand how to compile pyexpat on Windows. :-(
Well I like to use "pristine" binary builds from ZC to get reproducible environment, but having an RPM will mean that it'll only allow me to install it in one place, so only one Zope instance.
Not just one Zope instance, but probably just one Zope software_home for any particular major Zope release. E.g. you will likely not be able to install both Zope-2.7.0 and Zope-2.7.1 via RPM without doing some hackery, but you should be able to install Zope-2.7.1 and Zope 2.8.0 without fear of conflicts. Many instances can use the same software home and making an instance home will be very easy under 2.7+. It will also be a required step, so there's no chance you'll forget it. ;-)
Well ok, I know lots of ways to get what I need (rpm2cpio for one), but it will complicate my life a bit.
Does what I said above change this? - C
Chris McDonough wrote:
Well I like to use "pristine" binary builds from ZC to get reproducible environment, but having an RPM will mean that it'll only allow me to install it in one place, so only one Zope instance.
Not just one Zope instance, but probably just one Zope software_home for any particular major Zope release. E.g. you will likely not be able to install both Zope-2.7.0 and Zope-2.7.1 via RPM without doing some hackery, but you should be able to install Zope-2.7.1 and Zope 2.8.0 without fear of conflicts.
Many instances can use the same software home and making an instance home will be very easy under 2.7+. It will also be a required step, so there's no chance you'll forget it. ;-)
Well ok, I know lots of ways to get what I need (rpm2cpio for one), but it will complicate my life a bit.
Does what I said above change this?
Yes, that's a cleaner way to look at it. I'm not overly fond of several instance_homes with only one software_home as I really want to keep different sites completely separated (i.e., when upgrading the software for one site I don't want it to impact my other test sites). But that's probably only me. In this light an RPM is ok. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
I am happy with the proposal that started this thread. We do have a number of customers that use Zope on windows. Will there be a way to use several diffferent Zope instances when thay are run as services? Robert Am Donnerstag, 17. April 2003 17:53 schrieb Chris McDonough:
Ok if you dig into the build process, could you please ensure that
all
necessary .so files are built and shipped? See http://collector.zope.org/Zope/678
Sure, thanks. FWIW, I am trying at this very moment to understand how to compile pyexpat on Windows. :-(
Well I like to use "pristine" binary builds from ZC to get
reproducible
environment, but having an RPM will mean that it'll only allow me to install it in one place, so only one Zope instance.
Not just one Zope instance, but probably just one Zope software_home for any particular major Zope release. E.g. you will likely not be able to install both Zope-2.7.0 and Zope-2.7.1 via RPM without doing some hackery, but you should be able to install Zope-2.7.1 and Zope 2.8.0 without fear of conflicts.
Many instances can use the same software home and making an instance home will be very easy under 2.7+. It will also be a required step, so there's no chance you'll forget it. ;-)
Well ok, I know lots of ways to get what I need (rpm2cpio for one),
but
it will complicate my life a bit.
Does what I said above change this?
- C
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch
Hi Robert, Yes, each instance home should be able to run as its own service. - C ----- Original Message ----- From: "robert" <robert@redcor.ch> To: "Chris McDonough" <chrism@zope.com>; "Florent Guillaume" <fg@nuxeo.com> Cc: <zope-dev@zope.org>; <zope@zope.org> Sent: Friday, April 18, 2003 7:28 AM Subject: Re: [Zope] Re: [Zope-dev] What do we want in the way of Zope binary distributions? I am happy with the proposal that started this thread. We do have a number of customers that use Zope on windows. Will there be a way to use several diffferent Zope instances when thay are run as services? Robert
participants (18)
-
Andreas Jung -
Anthony Baxter -
Chris McDonough -
Dieter Maurer -
Dylan Reinhardt -
Florent Guillaume -
Fred L. Drake, Jr. -
J Cameron Cooper -
Jean Jordaan -
Jim Penny -
John Ziniti -
Nathan 'Nato' Uno -
Oliver Bleutgen -
Peter Sabaini -
Richard Jones -
robert -
Steve McMahon -
Toby Dickenson