[RFC] Pyrex .c file versioning

[Robert Collins]

On Tue, 2007-07-03 at 17:54 +0200, Vincent Ladeuil wrote:
> >>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:
> 
>     robert> I want to add another point to the .c versioning
>     robert> discussion, which is that I think more and more
>     robert> distros are getting the ability to build and ship
>     robert> from VCS rather than tarballs: I think we *should*
>     robert> ship the .c files in a branch.
> 
>     robert> At a minimum this could be the 0.18 etc branch, but I
>     robert> think it would really be better to put them in
>     robert> bzr.dev.
> 
>     robert> I think the churn due to different pyrex versions is
>     robert> addressable:
> 
>     robert>  - we can do a trivial script to change the paths
>     robert>  - we can nominate an official version we build with.
> 
> And most of the distros will prefer to use that official version
> and will be able to recreate the .c themselves.


>     robert> If we don't do this, I think its likely we will find
>     robert> distros that don't build the pyrex versions, or that
>     robert> encounter bugs related to having a different pyrex
>     robert> version in their build dependencies. Better for us to
>     robert> say 'heres the .c to build' consistently in all
>     robert> places we ship code.
> 
> I understand your wish to ease distro work.

Its not about the distros, its about our users.

> I don't like violating a rule that so many people fail to
> understand: don't version something that can be created from
> other files that are versioned.

Because as a rule of thumb it's ok. As a mantra its flawed. Rules are
made to be broken. (I could go on :)). Its like the derived data
argument in bzr itself: Don't treat derived data as though its not
derived, but *do* store/record/cache it if you get a sufficient win from
having it.

The .c files can not be created *solely* from the other files that are
versioned :).

> I reckon that I had suffer many times from checking out some
> package out of one VCS and be forced to create the configure
> script myself when auto[conf|make] were not installed.

Sounds like you would have benefited from having the generated files in
the toolchain built for you.

> But since we already have some core-devs involved in the debian
> package production, if we can provide some basic .rpm with right
> dependencies, we should cover most of the distros no ?

The problem is what .c file to recreate. We already know that some
versions of pyrex generate code that doesn't work quite right with
python 2.5 - and by pushing the generation of the .c code out to the
distro we also push responsibility for handling bugs that occur due to
using the wrong version of pyrex but that increases the ability for
distros to suffer from already solved bugs. DRY applies here I think -
why should distros have to repeat the learning process we are doing when
the file that is generated can be made churn free; is not unreasonably
large; and is portable to all platforms we support?

I feel more strongly about the release branches than trunk; but it does
make create an inconsistency between trunk and release branches like the
one I'm highlighting between release branches and tarballs - and I don't
think we desire such an inconsistency.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070704/9cee897f/attachment.pgp