Sender: tech-pkg-owner@NetBSD.org

I guess you did not see where I asked that folks also send email to my
pkgsrc alias so that I would be more likely to see their messages.

Quoting Laurent DAVERIO (daverio@cri.ensmp.fr):
> >If you use zope25-CMFPlone and have time to do an update, please assist.
> 
> from my experience as a Zope/Plone user on several platforms (FreeBSD, 
> Linux, Solaris, OS X, and even Windows), I would say that I prefer to keep 
> Zope/Plone out of the ports/packaging system for the following reasons :

Actually, just because they are in pkgsrc does not mean that you have
to use them. ;)  And there are some advantages to using pkgsrc.

> - Zope and Plone are very easy to install : basically, just unpack a tgz 
> file. True, Zope 2.7 needs a ./configure, make, make install routine, but 
> Zope is written mostly in Python, the C parts are small and I've never seen 
> gcc fail on them.

Granted, installing Zope by hand is fairly easy right now, and as you
say, is mostly Python + a few C parts.  But, by putting it into
pkgsrc, you can also use the buildlink framework to make sure that all
the dependency/linking issues for things like Python are handled.

> - Basically, the hardest part to get Zope running is to get Python (2.3.4 
> for Zope 2.7.2+) and its modules (PIL, odbc, PsycoPg, DCOracle2, ...) 
> running and, for this, pkgsrc/FreeBSD ports/DarwinPorts/... is invaluable.

Ahh... using pkgsrc, I had no problems getting the Python modules for
Zope+CMF+Plone and the handfull of other products I installed.  It was
even smart enough to make note of the fact that there was something
else depending on MySQL 4 and those other packages.

Only problem I have see so far is a pair of python module dependencies
which were not building, and those may have been due to the machine I
was building/testing on being a hybrid of 1.6.2 and 2.0. 

> - You may want to have several version of Zope and/or Plone coexist on the 
> same machine, and I'm not sure whether pkgsrc allows to do it more easily 
> than the manual way.

Yep.  Already thought of that, and it is handled via a variable.
Right now, I have two such trees, with their own instances.

> - Also, you *don't* want pkgsrc to decide when to switch Zope/Plone 
> versions for you. Plone has a very complex machinery, and is *VERY* 
> sensitive as to which version of Zope (and Python) you install it on. (e.g. 
> : Plone 2.0.4 + Zope 2.7.2 : mostly OK, except heavy sessioning - Plone 
> 2.0.4 + Zope 2.7.3b1 : no go). Similarly, you might want to test ZopeX3 
> (the preview of Zope 3) alongside Zope 2...

Ah, but as I said, you do not have to use pkgsrc, or change to the new
version when pkgsrc changes.  And your point about the version issues
is a strong argument for pkgsrc.  After all, why should everyone have
to figure out that particular combinations of Python + Zope + Plone do
not work??  Anyone maintaining the new pkgsrc packages (I certainly
will be submitting them with my name as the maintainer) will hopefully
have the intelligence, time and knowledge to make sure that things
work before committing changes.


So, in summary, here are some good reasons for having them in pkgsrc.

- It can maintain dependencies for you, making sure you have a good
  combination of OS+Python+Zope+CMF+Plone+xxx+yyy without you having
  to take the trouble to do this manually.
- Not mentioned above, pkgsrc helps you keep track of where all the
  files (outside of the Zope instance directories) are located, so
  that you can cleanly remove them when you want to remove Zope or
  want to upgrade it.
- Not mentioned above, pkgsrc also helps you keep track of modified or
  corrupted files (see pkg_admin for more info)

> Just my two cents, although I realize it might be slightly offtopic...

Very much on-topic for both the group and the thread, and thanks for
your input.

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!