[RFC] Pyrex .c file versioning
v.ladeuil+lp at free.fr
Tue Jul 3 16:54:39 BST 2007
>>>>> "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> I think the churn due to different pyrex versions is
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.
More information about the bazaar