r2126 - in zope2.12/branches/with-revived-tarball/debian (16 files)

[Michael Mulich]

Jonas-

What needs to be done about the copyright? I've put some logic in the 
upstream to generate a rudimentary copyright file during the fetch 
process (invoked by get-orig-source).

After looking at DEP5 (http://dep.debian.net/deps/dep5/) and looking at 
the current copyright file, I'm not exactly sure where to go.

I know of of three licenses in the source. Most of the source is under 
ZPL 2.1. The other two licenses are for Pip (MIT) and the upstream 
source (GPL). If the resulting deb does not contain code from either Pip 
or the upstream, do references need to be included for MIT and GPL?

On 11/13/10 7:13 PM, Michael Mulich wrote:
> On 11/13/10 2:49 PM, Jonas Meurer wrote:
>> On 12/11/2010 Michael Mulich wrote:
>>> On 11/12/10 2:08 PM, Jonas Meurer wrote:
>>>> On 12/11/2010 Michael Mulich wrote:
>>>>> On 11/12/10 1:03 PM, Jonas Meurer wrote:
>>>> the best solution would be to automate all preliminary steps in the
>>>> debian/rules makefile:
>>>>
>>>> a target called 'get-orig-source', should automate the process of
>>>> building a custom orig.tar.gz from the upstream zope2.12 tarball and
>>>> all
>>>> required zope dependencies.
>>>> this target must not be invoked at build process, but instead needs to
>>>> be invoked manually.
>>>>
>>>> many debian packages already provide this 'get-orig-source' target. see
>>>> http://www.debian.org/doc/debian-policy/ch-source.html chapter 4.9 for
>>>> more information.
>>>>
>>>> a get-orig-source target also has the advantage, that you don't need to
>>>> maintain a custom zope source tarball, but instead have code that
>>>> automates the preparation task, which easily can be updated for
>>>> subsequent zope releases.
>>>>
>>>> the custom build scripts (e.g. buildout receipe, configure script)
>>>> should be provided as debian patches in debian/patches, and applied to
>>>> the source at package build process instead of being part of the
>>>> (crafted) source tarball.
>>>>
>>> The tarball was created out of a request from a few people in the
>>> zope/plone community that wanted something more distribution
>>> agnostic. So this tarball solution is something that can also be
>>> used in other distribution environments. If it's an issue, we can
>>> always pull this into the deb, but I'd rather not maintain two
>>> versions of the same process.
>>>
>>> By the way, I'm no longer using zc.buildout in the build process. :)
>>>
>>> I've also got documentation about the tarball up at
>>> http://weblion.psu.edu/static/zope2-tarballs/docs/current/
>>
>> ok, understood the point. but i'd suggest to implement the
>> 'get-orig-source' target anyway. other distributions can use it as well.
>>
>
> I definitely agree. I was actually looking at something similar in
> python-markdown. Except, python-markdown's procedure is not part of the
> rules file, it's a separate script; so I like the get-orig-source target
> better.
>
>> at least i would implement a script which crafts your custom tarball
>> from upstream sources automaticly in order to make the tarball creation
>> process more transparent.
>>
>
> Yeah, that sounds like a good idea. I foresee one small issue though.
> We'll need to test it but I think the feature I use to 'fetch' the
> source is only in 0.8.2, but it may be in 0.8.1 which is packaged in
> unstable. We'll need to test it.
>
> I'll also point out another flaw. I've neglected it up to this point,
> but I want to point it out before you notice another mistake. ;)
> I'm not pinning to a particular version of python. Since we are building
> binaries I imagine we will likely need to do this.
> And, I just noticed that the tarball's make clean doesn't clean the
> source builds (e.g. source/Record/build/*). These do get paved over on
> rebuild, but there is no guarantee that will be the case in the future.

I've made a few modification to the upstream source. The get-orig-source 
fetches only what is needed to build deb rather than all the 
dependencies. For example, zope.i18n is excluded from the fetch process 
since it is satisfied by the python-zope.i18n package. How do you feel 
about this?

Thanks.

-Michael Mulich (pumazi)