alex.wulms at scarlet.be
Sun Jun 14 07:29:57 EDT 2009
We should eventually (as soon as we have fleshed out the protocol details)
rewrite crccache-client to be an independent module in stead of a mod-cache
storage handler. Reason is that crccache-client needs to be involved in many
cases when mod-cache would normally not call a storage handler at all. Once
we have rewritten crccache-client as a stand-alone module, we will
automagically get rid of the mod cache headers dependency. So I see this
dependency as a temporarily problem that we should not spend too much effort
on to resolve.
Thanks and brs,
Op zondag 14 juni 2009, schreef Toby Collett:
> Hi all,
> I have just committed some work which allows creation of deb packages, in
> the process I have moved a bunch of files around and created some new
> Makefile targets, 'dist' 'deb' and 'debbin' which produce a tarball, source
> deb and binary debs respectively.
> Things to watch out for:
> 1) the tarball (and therefore deb targets) currently use the git archive
> command, this creates a tarball from the latest commit rather than working
> copy so commit before you test packaging changes (anyone know how to fix
> this behaviour?)
> 2) Currently we need to distribute the apache mod cache headers in order to
> be able to build as these dont seem to be installed by apache, this raises
> a couple of points, firstly it implies its a private API and therefore
> likely to change, and secondly when it does change we will need to manually
> grab a new copy of them. So probably we should copy the behaviour we want
> from these module, or lobby for them to become a public API...
> Martin, you should be able to create an RPM package pretty easily now using
> the deb as a starting point.
> At some point I will upload the package to my Ubuntu/launchpad ppa so
> people can play without getting the source, however might not be for a few
More information about the Http-crcsync