Hi all, I am working towards a unified Zope configuration and installation system on a branch of Zope named the 'chrism-install-branch'. I have given the buildout process on that branch the ability to create an RPM distribution of Zope. I intend later to give the buildout process the ability to create Debian .debs as well and maybe Solaris packages... I am doing this with the expectation that we might be able to provide RPM and .deb distros of Zope from zope.org instead of our current "generic Linux as tarball" distro. I haven't looked yet at the Debian packaging of Zope (by Gregor Hoffleit), but I intend to do that next to get some more ideas. I know there are already at least two flavors of Zope RPMs which Jeff Rush helped to package. There are a number of differences between the packaging of the RPMs generated by my branch and the packaging of Jeff's RPMs: - One of Jeff's distros breaks Zope up into many different packages, while another installs it as one or two. Mine only has one distribution flavor: a single package. - Jeff's puts some stuff into the current prevailing python's site-packages directory and some other stuff into /usr/share/zope. Mine puts nothing into site-packages, and installs all Zope software into /opt/zope. - Jeff's creates an INSTANCE_HOME in /var/zope. Mine creates an INSTANCE_HOME in /var/opt/zope. I don't know if this is the right thing but in reading the Linux FHS, it advises to not create subdirectories of var directly... so I don't. - Jeff's puts pid files into /var/run, while mine creates pid files directly in INSTANCE_HOME/var. - Jeff's puts log files into /var/log while mine puts them into INSTANCE_HOME/var. I am wondering if: - anybody has opinions on the packaging layout. Why is it advantageous to have many packages rather than one? - anybody has any opinions of where Zope files distributed via RPMs and debs should really go, especially wrt to the Linux FHS. I'm not sure there is a right answer, but I don't know beans about this, so I figure I'll ask. A file named 'Zope.spec.in' is attached to this email which is the input file to create a Zope RPM spec file during the make process, to give a better idea of how this works. Thanks! - C
This looks GREAT!! A couple of points: *) Python 2.2.x ?? This is scheduled for Zope 3 ?? Is there any way this could find its way in to a 2.x release? *) Byte compiling: Why not schedule an 'at' job to do the byte compile? *) Ownership/perms on the 'var' dir, this will need to be the same as the user Zope runs as, which I assume is not the same as ${zopeuser} Minor personal request: *) Is there any way to detect if apache is installed, and have zope run as the apache user? This would be great for CGI support, etc. Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Chris McDonough" <chrism@zope.com> To: <zope-dev@zope.org> Cc: <jrush@taupro.com>; <flight@debian.org> Sent: Saturday, October 12, 2002 11:28 PM Subject: [Zope-dev] Zope RPMs/debs and Linux FHS
Hi all,
I am working towards a unified Zope configuration and installation system on a branch of Zope named the 'chrism-install-branch'.
I have given the buildout process on that branch the ability to create an RPM distribution of Zope. I intend later to give the buildout process the ability to create Debian .debs as well and maybe Solaris packages... I am doing this with the expectation that we might be able to provide RPM and .deb distros of Zope from zope.org instead of our current "generic Linux as tarball" distro. I haven't looked yet at the Debian packaging of Zope (by Gregor Hoffleit), but I intend to do that next to get some more ideas.
I know there are already at least two flavors of Zope RPMs which Jeff Rush helped to package. There are a number of differences between the packaging of the RPMs generated by my branch and the packaging of Jeff's RPMs:
- One of Jeff's distros breaks Zope up into many different packages, while another installs it as one or two. Mine only has one distribution flavor: a single package.
- Jeff's puts some stuff into the current prevailing python's site-packages directory and some other stuff into /usr/share/zope. Mine puts nothing into site-packages, and installs all Zope software into /opt/zope.
- Jeff's creates an INSTANCE_HOME in /var/zope. Mine creates an INSTANCE_HOME in /var/opt/zope. I don't know if this is the right thing but in reading the Linux FHS, it advises to not create subdirectories of var directly... so I don't.
- Jeff's puts pid files into /var/run, while mine creates pid files directly in INSTANCE_HOME/var.
- Jeff's puts log files into /var/log while mine puts them into INSTANCE_HOME/var.
I am wondering if:
- anybody has opinions on the packaging layout. Why is it advantageous to have many packages rather than one?
- anybody has any opinions of where Zope files distributed via RPMs and debs should really go, especially wrt to the Linux FHS. I'm not sure there is a right answer, but I don't know beans about this, so I figure I'll ask. A file named 'Zope.spec.in' is attached to this email which is the input file to create a Zope RPM spec file during the make process, to give a better idea of how this works.
Thanks!
- C
On Sun, 2002-10-13 at 10:31, Adrian Hungate wrote:
This looks GREAT!!
Thanks a lot..
A couple of points: *) Python 2.2.x ?? This is scheduled for Zope 3 ?? Is there any way this could find its way in to a 2.x release?
I believe Zope 2.7 will require Python 2.2.X. It's my hope to merge this into the Zope trunk at some point in the near future (which will in turn become Zope 2.7 at some point).
*) Byte compiling: Why not schedule an 'at' job to do the byte compile?
The only reason I care about when the files are compiled is that if the files are byte-compiled in the rpm build root, tracebacks will contain references to the buildroot in the python filenames. I could do it in postinstallation, but then I'd need to clean up the py[co] files manually during uninstall which seems a little icky. I suppose for "real" releases we could just not use a buildroot, but this is not too convenient.
*) Ownership/perms on the 'var' dir, this will need to be the same as the user Zope runs as, which I assume is not the same as ${zopeuser}
Well, I had thought for default installs, the %{zopeuser} will be "zope" and this user will indeed be both the owner of the var dir and the owner of the process. Do you think there is a better way?
Minor personal request: *) Is there any way to detect if apache is installed, and have zope run as the apache user? This would be great for CGI support, etc.
What user does apache run as? "apache"? Thanks! - C
*) Byte compiling: Why not schedule an 'at' job to do the byte compile?
The only reason I care about when the files are compiled is that if the files are byte-compiled in the rpm build root, tracebacks will contain references to the buildroot in the python filenames. I could do it in postinstallation, but then I'd need to clean up the py[co] files manually during uninstall which seems a little icky.
I suppose for "real" releases we could just not use a buildroot, but this is not too convenient.
Chris, please use always a buildroot ! You can set an option in the compile-all script that tell python to set the real realase path in the tracebacks. Regards, Dirk
On Mon, 2002-10-14 at 03:14, Dirk Datzert wrote:
Chris,
please use always a buildroot ! You can set an option in the compile-all script that tell python to set the real realase path in the tracebacks.
This is true, but the branch no longer uses compileall. Instead, distutils does the work. I suppose we could fall back onto compileall. Thanks, - C
On Sun, Oct 13, 2002 at 04:12:34PM -0400, Chris McDonough wrote: | > *) Ownership/perms on the 'var' dir, this will need to be the same as the | > user Zope runs as, which I assume is not the same as ${zopeuser} | | Well, I had thought for default installs, the %{zopeuser} will be "zope" | and this user will indeed be both the owner of the var dir and the owner | of the process. Do you think there is a better way? Seems like very good solution. | > Minor personal request: | > *) Is there any way to detect if apache is installed, and have zope run as | > the apache user? This would be great for CGI support, etc. | | What user does apache run as? "apache"? www-data on debian. []'s -- Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18 ppc A feature is nothing more than a bug with seniority. -- Unknown source
Il dom, 2002-10-13 alle 00:28, Chris McDonough ha scritto:
- Jeff's puts some stuff into the current prevailing python's site-packages directory and some other stuff into /usr/share/zope. Mine puts nothing into site-packages, and installs all Zope software into /opt/zope.
- Jeff's creates an INSTANCE_HOME in /var/zope. Mine creates an INSTANCE_HOME in /var/opt/zope. I don't know if this is the right thing but in reading the Linux FHS, it advises to not create subdirectories of var directly... so I don't.
- Jeff's puts pid files into /var/run, while mine creates pid files directly in INSTANCE_HOME/var.
perfect. please do that for debian packages too and let /usr for official debian packages of Zope.
- anybody has opinions on the packaging layout. Why is it advantageous to have many packages rather than one?
you can install only what you really need. for example debian as one package for every Product not included in base Zope, so, if i want the CMF i have only to do: apt-get install zope-cmfdefault
- anybody has any opinions of where Zope files distributed via RPMs and debs should really go, especially wrt to the Linux FHS. I'm not sure there is a right answer, but I don't know beans about this, so I figure I'll ask. A file named 'Zope.spec.in' is attached to this email which is the input file to create a Zope RPM spec file during the make process, to give a better idea of how this works.
/opt and /var/opt is the right place. zope.org is a "software vendor" and stuff from software vendors should gointo /opt. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Best friends are often failed lovers. -- Me
On Sun, 2002-10-13 at 10:54, Federico Di Gregorio wrote:
- Jeff's puts pid files into /var/run, while mine creates pid files directly in INSTANCE_HOME/var.
perfect. please do that for debian packages too and let /usr for official debian packages of Zope.
Do you mean I should use /usr or I should not? I see that Gregor's package uses /usr/lib/zope to store the software home files... I'm not sure what this means to the FHS. I also see that the existing debian Zope product packages (at least the ones I've looked at) put their products into /usr/lib/zope/Products.
you can install only what you really need. for example debian as one package for every Product not included in base Zope, so, if i want the CMF i have only to do:
apt-get install zope-cmfdefault
Right.. this is very cool. Luckily, I'm only worrying about Zope itself at the moment... Product packagings are a different story.
- anybody has any opinions of where Zope files distributed via RPMs and debs should really go, especially wrt to the Linux FHS. I'm not sure there is a right answer, but I don't know beans about this, so I figure I'll ask. A file named 'Zope.spec.in' is attached to this email which is the input file to create a Zope RPM spec file during the make process, to give a better idea of how this works.
/opt and /var/opt is the right place. zope.org is a "software vendor" and stuff from software vendors should gointo /opt.
OK, I think so too... I'd like to hear the opinions of the existing debian and rpm maintainers as well, though... A tremendous amount of effort has been put into packaging Debian and RPM Zope packages. I want to make sure that what I do doesn't step on anybody's toes in this realm... it will be problematic if we start to create rpm and deb distros that are completely different than the ones that already exist. At the same time, it would be nice if we could come up with some sort of cross-platform standard for file locations. - C
Looks good, I was planning to start from scratch with building a RPM for 2.6 that would work on at least RedHat 8.x AND 7.x.. Coincidentally, this is something I planned to start on tomorrow! :-) Instead, I'll take a few hours tomorrow to test your spec on RedHat 8.0, it would be *really* good if this could be the basis of and future 2.6 / 2.7 packaging efforts...
- anybody has opinions on the packaging layout. Why is it advantageous to have many packages rather than one?
Zope, Zope-zserver and Zope-PCGI packages seem like a good idea. Most RPM dists seem to have at least a "-server" sub package if they provide a daemon (eg postgresql). Init scripts, the "data" dir, etc all go in the "-server" subcomponent [adam@blackbox adam]$ rpm -qa | grep postgresql postgresql-7.2.2-1 postgresql-server-7.2.2-1 postgresql-libs-7.2.2-1 [adam@blackbox adam]$ rpm -ql postgresql-server /etc/rc.d/init.d/postgresql /usr/bin/initdb /usr/bin/initlocation /usr/bin/ipcclean /usr/bin/pg_ctl /usr/bin/pg_passwd /usr/bin/postgres /usr/bin/postmaster /usr/lib/pgsql /usr/lib/pgsql/backup /usr/lib/pgsql/backup/pg_dumpall_new /usr/lib/pgsql/plpgsql.so /usr/share/locale/cs/LC_MESSAGES/postgres.mo /usr/share/locale/de/LC_MESSAGES/postgres.mo /usr/share/locale/hu/LC_MESSAGES/postgres.mo /usr/share/locale/ru/LC_MESSAGES/postgres.mo /usr/share/locale/zh_CN/LC_MESSAGES/postgres.mo /usr/share/locale/zh_TW/LC_MESSAGES/postgres.mo /usr/share/man/man1/initdb.1.gz /usr/share/man/man1/initlocation.1.gz /usr/share/man/man1/ipcclean.1.gz /usr/share/man/man1/pg_ctl.1.gz /usr/share/man/man1/pg_passwd.1.gz /usr/share/man/man1/postgres.1.gz /usr/share/man/man1/postmaster.1.gz /usr/share/pgsql /usr/share/pgsql/pg_hba.conf.sample /usr/share/pgsql/pg_ident.conf.sample /usr/share/pgsql/postgres.bki /usr/share/pgsql/postgres.description /usr/share/pgsql/postgresql.conf.sample /var/lib/pgsql /var/lib/pgsql/.bash_profile /var/lib/pgsql/backups /var/lib/pgsql/data
- anybody has any opinions of where Zope files distributed via RPMs and debs should really go, especially wrt to the Linux FHS. I'm not sure there is a right answer, but I don't know beans about this, so I figure I'll ask. A file named 'Zope.spec.in' is attached to this email which is the input file to create a Zope RPM spec file during the make process, to give a better idea of how this works.
AFAIK on RedHat /opt or "mixed in" (/usr/bin etc) is fine, the argument goes "if RPM tracks all the files for you, why use /usr/local or /opt?" /opt is used too, the only problem being that it isn't often created separate from the "/" partition, so there often isn't alot of space there! One "trick" to note is for creating the inituser (from 2.5.1): # Declare the Superuser of the Default Zope Project rm $RPM_BUILD_ROOT/usr/share/zope/inituser %{PYTHONAPP} $RPM_BUILD_ROOT/usr/bin/zpasswd -u admin -p 123 $RPM_BUILD_ROOT/var/zope/inituser chmod 0640 $RPM_BUILD_ROOT/var/zope/inituser Adam
On Sun, 2002-10-13 at 12:15, Adam Manock wrote:
I was planning to start from scratch with building a RPM for 2.6 that would work on at least RedHat 8.x AND 7.x.. Coincidentally, this is something I planned to start on tomorrow! :-)
Oh happy coincidences! ;-) FWIW, in order for my spec file to make any sense in the context of Zope, you'll need to check out the 'chrism-install-branch' of Zope via: cvs -d :pserver:cvs.zope.org:/cvs-repository -d ChrisMInstallBranch -r chrism-install-branch Zope Then: cd ChrisMInstallBranch ./configure make rpmdist Note that the current spec file claims that Python >= 2.2.1 is required to install the rpm. This is only because the RedHat-shipped 2.2.0 doesn't include the compiler package, required for Zope to run properly. It should also work with 2.1.3, but RedHat doesn't have any 2.1.X RPMs. :-( To make matters worse, Python 2.2.1 has a few bugs that are known to cause Zope to crash, so the spec file should really depend on either "== 2.1.3" or "== 2.2.2". In any case, if you've got patches, send them my way! I am hoping that the chrism-install-branch will become the basis for the configuration and packaging machinery for Zope 2.7. It supports a "configure; make; make install" install process for source distros that is easy to adapt for binary distros.
Instead, I'll take a few hours tomorrow to test your spec on RedHat 8.0, it would be *really* good if this could be the basis of and future 2.6 / 2.7 packaging efforts...
2.6 doesn't (and likely wont) have the machinery for it, but 2.7 should. It'd be very cool to be ahead of the game for 2.7 as far as packaging and distribution goes...
Zope, Zope-zserver and Zope-PCGI packages seem like a good idea. Most RPM dists seem to have at least a "-server" sub package if they provide a daemon (eg postgresql). Init scripts, the "data" dir, etc all go in the "-server" subcomponent
In my mind, Zope doesn't really have a client subcomponent (Zserver really is part of Zope proper), but it might be nice to break out PCGI/FCGI support.
AFAIK on RedHat /opt or "mixed in" (/usr/bin etc) is fine, the argument goes "if RPM tracks all the files for you, why use /usr/local or /opt?" /opt is used too, the only problem being that it isn't often created separate from the "/" partition, so there often isn't alot of space there!
Darn. That's true. The FHS says that opt is a viable place for this kind of thing (whereas /usr maybe isnt).. The resulting /opt directory structure is also only about 26MB, as well so maybe it's OK?
One "trick" to note is for creating the inituser (from 2.5.1):
# Declare the Superuser of the Default Zope Project rm $RPM_BUILD_ROOT/usr/share/zope/inituser %{PYTHONAPP} $RPM_BUILD_ROOT/usr/bin/zpasswd -u admin -p 123 $RPM_BUILD_ROOT/var/zope/inituser chmod 0640 $RPM_BUILD_ROOT/var/zope/inituser
Yeah, thanks... I'd rather not ship a default password because as soon as we do, there's bugtraq and security people crawling all over the place yelling at us. I added a "write_inituser" command to the zctl front-end for this purpose, so folks will need to use it before they can log in to Zope. It would be nice if RPM installers offered ubiquitous interactivity the way that Debian's does, but alas. - C
On Sat, Oct 12, 2002 at 06:28:37PM -0400, Chris McDonough wrote:
Hi all,
I am working towards a unified Zope configuration and installation system on a branch of Zope named the 'chrism-install-branch'.
I have given the buildout process on that branch the ability to create an RPM distribution of Zope. I intend later to give the buildout process the ability to create Debian .debs as well and maybe Solaris packages... I am doing this with the expectation that we might be able to provide RPM and .deb distros of Zope from zope.org instead of our current "generic Linux as tarball" distro. I haven't looked yet at the Debian packaging of Zope (by Gregor Hoffleit), but I intend to do that next to get some more ideas.
I will be honest here. I don't care a lot about how the debian files are packaged, or where. But I do not want to see two sets of debs with differing layouts. I would rather that either Chris become an official debian maintainer and take over zope (and thereby upload it to the normal repositories), or that he leave debian packaging to Gregor, or whoever succeeds him. There is no reason that zope.org cannot have a short paragraph or two on installing zope under debian, which points people to the normal repositories; or alternatively, there is no reason that zope.org cannot mirror debian's zope and related packages. Jim Penny
I will be honest here. I don't care a lot about how the debian files are packaged, or where. But I do not want to see two sets of debs with differing layouts.
Not only talking about debs distro layouts. There should be one install instruction for all linux distros, which takes care about FHS. This should be official published under zope.org. On this base an RPM can build. If installation places changes from 2.4.4/2.5.1 to 2.6 than it simple changes. A notification mail on RPM install can tell that to the user. Distro maintainer like SuSE doing that this way. Regards, Dirk
On Mon, Oct 14, 2002 at 06:04:33PM +0200, Dirk Datzert wrote:
I will be honest here. I don't care a lot about how the debian files are packaged, or where. But I do not want to see two sets of debs with differing layouts.
Not only talking about debs distro layouts. There should be one install instruction for all linux distros, which takes care about FHS. This should be official published under zope.org. On this base an RPM can build.
If installation places changes from 2.4.4/2.5.1 to 2.6 than it simple changes. A notification mail on RPM install can tell that to the user.
Yes, but... user migration is not the real issue. Packager migration is more important. I mean, look, a debconf question, or a post-install question could ask whether the user wanted his location maintained, and build a symbolic link, or it could move the data. The SuSe model might work very well for SuSe, but it will not work well for Debian. Debian has a strong tradition of in-place upgrades, and more importantly, requires a lot of internal coordination; there are more than 30 packages dependent on the current debian zope layout, and probably more than 20 maintainers. Changing the location that packages are installed in (currently /usr/lib/zope/lib/python/Products) would probably require 30 days or so. Again, I see no advantage, even if file location is identical, to there being more than one repository of .debs for zope. And I would think that zope.org would agree. Debian has a very substantial set of mirrors over which to distribute the load. Zope.org would have to pay for much bandwidth on days that new .debs came into being (much deb pulling is automated, so it is much more spiky than .rpm pulling). Moreover, having more than one such repository will simply create problems for end users. Either we will have a repeat of the ximian debacle, where it was almost impossible to get new, upgraded packages from the canonical repositories (and this included security upgrades!), or we will see that most users are not running the zope.org packages anyway, since their revision numbers will differ (and probably be lower). And frankly, doing debian packaging right is a PITA, and doing it almost right is pretty pointless. I have no opposition to an attempt to standardize the location of ZOPE_HOME and LOCATION_HOME. (I also don't see it as that big a deal, people to whom this matters, who are presumed capable enough to be trusted with the root password, should be capable of reading /usr/share/doc/zope/README.Debian.gz.) But, if zope.org wishes to maintain a set of .deb packages, then zope.org really, really, needs to become the official debian packager (and hence the suggestion that Chris become an official debian developer); or they really, really need to stay out of it, and simply point debian users elsewhere. Now, if I wanted to have a debian related wish, it would be that there be a robust ZOPE_HOME2 into which one puts local products and products not installed via .debs (probably /usr/local/lib/zope/python/Products, although the python may not be needed). Jim Penny
Distro maintainer like SuSE doing that this way.
Regards, Dirk
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Mon, 2002-10-14 at 13:03, Jim Penny wrote:
I have no opposition to an attempt to standardize the location of ZOPE_HOME and LOCATION_HOME. (I also don't see it as that big a deal, people to whom this matters, who are presumed capable enough to be trusted with the root password, should be capable of reading /usr/share/doc/zope/README.Debian.gz.) But, if zope.org wishes to maintain a set of .deb packages, then zope.org really, really, needs to become the official debian packager (and hence the suggestion that Chris become an official debian developer); or they really, really need to stay out of it, and simply point debian users elsewhere.
FWIW, I have no intention of doing anything to upset the apple cart.
From what I've heard so far, it sounds like it would be quite difficult to standardize file locations. It's much easier for me to let it go and to hell with standardization. If I can make any of the current maintainers' lives easier by creating a "make debdist" based off the current control file and whatnot that "does the right thing" for the current Debian Zope file layout, I would be happy do do so, I just need to know that there's demand.
- C
On Mon, 2002-10-14 at 11:50, Jim Penny wrote:
I will be honest here. I don't care a lot about how the debian files are packaged, or where. But I do not want to see two sets of debs with differing layouts. I would rather that either Chris become an official debian maintainer and take over zope (and thereby upload it to the normal repositories), or that he leave debian packaging to Gregor, or whoever succeeds him. There is no reason that zope.org cannot have a short paragraph or two on installing zope under debian, which points people to the normal repositories; or alternatively, there is no reason that zope.org cannot mirror debian's zope and related packages.
Agreed. It would be nice, however, to have the files placed by default in the same places under RedHat and Debian binaries, and the source distro, however, so the instructions are uniform. I realize this may not be a a good idea in the face of historical distributions, and I wouldn't even think of doing it without buy-in from all interested parties. I'd rather not become the Debian maintainer, so there's some self-interest here as well. ;-) - C
participants (7)
-
Adam Manock -
Adrian Hungate -
Chris McDonough -
Dirk Datzert -
Federico Di Gregorio -
Jim Penny -
Sidnei da Silva