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

[Michael Mulich]

Jonas-

On 11/25/10 11:29 AM, Jonas Meurer wrote:
> On 25/11/2010 Jonas wrote:
>> On 13/11/2010 Michael Mulich wrote:
>>>>> 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.
>>>
>>> Watch for the next changeset and give it another go. Thanks.
>>
>> To be honest, I'd prefer a solution where
>> - the original Zope tarball is fetched by get-orig-tarball

I believe you mean get-orig-source, no? (see also, 
http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-targets)

>> - your custom scripts are stored as patches in debian/patches/...

As I said before, I didn't want to do this because any updates that may 
happen would need to take place in multiple locations. However, as the 
scripts become more mature and generic, I definitely agree that they 
should be placed in debian/patches. The scripts should be nearing a 
level of maturity, so I will transfer these into debian/patches soon. 
See below as well...

>> - debian/rules invokes your scripts at the beginning of the build
>>    process.
>>
>> This build process could be adopted by other distributions. with the
>> current solution, distributions will always rely on you updating your
>> custom tarballs before new zope versions can be packaged.
>
> sorry, meant it the following way:
>
> get-orig-tarball:
> 	- fetch original Zope tarball to a tmpdir
> 	- change to the tmpdir
> 	- invoke your custom scripts from sth. like debian/build-scripts
> 	- tar&  gz the result
> 	- remove everything except the tarball
>

We've basically got this, except that the custom script(s) are not 
locally available. I'm working towards generalizing these enough that we 
can use them else where. For instance, I'm currently using these scripts 
to develop a Plone 4.0 package.

> build-process:
> 	- leave the way it is
>

-Michael Mulich (pumazi)