Differences between revisions 8 and 9
Revision 8 as of 2011-03-17 20:44:27
Size: 4067
Editor: ?JonasMeurer
Comment: add small summary
Revision 9 as of 2011-03-18 23:47:28
Size: 5133
Editor: ?MichaelMulich
Comment:
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
   * There is nothing out of the ordinary going on here. The current implementation follows a typical build/install process most projects use: 1) fetch 2) configure 3) build 4) install (MichaelMulich)

     1. '''Fetching the source''' is done by debian/build-scripts/fetch.py. It uses the well known Pip install's functionality to download the required libraries, while excluding the libraries that are already packaged in Debian.
     1. '''Configuring the build''' is done using a configuration script written in Python. This is included in a patch under debian/patches/build-resources.patch. This script basically does autoconf like things. Most importantly, it generates a Makefile.
     1. '''Build the application libraries'''. It uses distutils to build the libraries out to a staging area.
     1. '''Install the build libraries'''. This simply puts the build libraries and the proper Debian locations.

   * The primary focus of the scripts are to use minimal dependencies and exclude libraries that we know are already packaged. (MichaelMulich)

Zope2 Packaging IRC Meeting

The last Zope2 versions that were packaged for Debian, namely Zope2.10 and Zope2.11, are long obsoleted. With Zope2.12, the build system changed fundamentally. Unfortunately, the new Zope2 build system, built on Python Buildout, is not very friendly to packagers.

That's the reason, why no attempt to package Zope2.12 for the Debian distribution was successful so far. Yet, some developers and users, among them Michael Mulich, Gael Le Mignot and I, have strong interest in Debian Zope2 packages.

Thus we're planned an IRC meeting to discuss the details of prospective Zope2 Debian packages, and to join the efforts of packaging Zope2.12+ for Debian.

Suggested Dates

Please add your Names to the list if you're able to attent the meeting on the proposed dates.

  • Fri, 18 Mar 2011 12:00:00 UTC (?GaelLeMignot, ?MichaelMulich)

  • Fri, 18 Mar 2011 14:00:00 UTC (?GaelLeMignot, ?MichaelMulich)

  • Sat, 19 Mar 2011 12:00:00 UTC (?GaelLeMignot, ?MichaelMulich)

  • Sat, 19 Mar 2011 14:00:00 UTC (?GaelLeMignot, ?MichaelMulich)

  • Fri, 15 Apr 2011 11:00:00 UTC (?JonasMeurer, ?GaelLeMignot, ?MichaelMulich)

  • Fri, 15 Apr 2011 13:00:00 UTC (?JonasMeurer, ?GaelLeMignot, ?MichaelMulich)

  • Sat, 16 Apr 2011 11:00:00 UTC (?JonasMeurer, ?MichaelMulich)

  • Sat, 16 Apr 2011 13:00:00 UTC (?JonasMeurer, ?MichaelMulich)

Agenda

Below is a first list of topics that should be discussed at the meeting. Feel free to extend the list.

  • How to package upstream sources? (?JonasMeurer)

    • The common way in Debian is to package unchanged upstream sources and patch them with patches maintained in the subdirectory debian/patches.
    • Michaels packaging approach did it differently in the past: He maintained a custom source tarball that contains already modified upstream sources, and built the package on top of this custom tarball. I'd like to discuss pros and cons of this approach.
  • Using packaged Zope dependencies or not? (?JonasMeurer)

    • Debian already contains several dependencies of the Zope2 server as seperate packages.
    • (Not only) for security reasons, it is considered as bad style to use local copies of packaged code within a source package. Instead the package should build-depend on the dependencies and use their code.
    • This is not an option for some Zope2 dependencies, as the Zope2 server depends on particular versions of the dependencies. Unfortunately these dependencies aren't backwards compatible. Still we should take a deeper look at which dependencies could be used, and which need to be included in the Zope2 source tarball.
  • Understanding Michaels custom build system (?JonasMeurer)

    • I don't know much about buildout and all that fancy python stuff, and to be honest, I don't understand the build system Michael uses in his Zope2.12 packaging approach. Maybe he can explain it in easy words to me. I would very much appreciate it.
    • There is nothing out of the ordinary going on here. The current implementation follows a typical build/install process most projects use: 1) fetch 2) configure 3) build 4) install (?MichaelMulich)

      1. Fetching the source is done by debian/build-scripts/fetch.py. It uses the well known Pip install's functionality to download the required libraries, while excluding the libraries that are already packaged in Debian.

      2. Configuring the build is done using a configuration script written in Python. This is included in a patch under debian/patches/build-resources.patch. This script basically does autoconf like things. Most importantly, it generates a Makefile.

      3. Build the application libraries. It uses distutils to build the libraries out to a staging area.

      4. Install the build libraries. This simply puts the build libraries and the proper Debian locations.

    • The primary focus of the scripts are to use minimal dependencies and exclude libraries that we know are already packaged. (?MichaelMulich)

  • Helping with Debian packaging issues (?JonasMeurer)

    • To me it seems like Michael known much more about Zope and Python than I do, on the other hand I have experience in packaging software for Debian (building debs). Thus I'll gladly answer any questions he (or others) have regarding Debian packaging guidelines, Debian policy and so on.
  • Working towards a long-term solution for packaging Zope2 for Debian (?JonasMeurer)

    • There is need for Zope2 packages in Debian. A lot of people do run Zope2 instances on Debian Servers. I've the impression, that Zope2 development will be continued upstream as well. In fact it seems to me, that Zope2 development is much more active in the last months, than Zope3 development.
    • The Debian dzhandle and zope-debhelper tools are still very useful for maintaining Zope2 instances. I'd like to keep them for Zope2.12+ instances as well.
    • Thus I'd like to work out a long-term solution for Zope2 Debian Packages. One that is compatible with Debian policy and security team guidelines.

Looking forward to the IRC meeting (?JonasMeurer)