[RFC] Pyrex .c file versioning

[Vincent Ladeuil]

>>>>> "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.

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.

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.

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 ?

Otherwise producing the .c file in the 0.18 etc branches will be
my personal preference.

  Vincent