Re: dgit and upstream git repos
Theodore Ts'o <firstname.lastname@example.org> writes:
> The flip side is that you can get burned by people trying to compile
> from your git tree on either significantly older or significantly newer
> system than what you typically use to develop against, and if autoconf
> and friends have introduced incompatible changes to the autoconf macros
> used in your configure.in.
That's not a flip side -- that's why I have tarball releases. You can
take your choice of using the cutting edge, at which point you need
appropriate development tools, or you can use a tarball release, which is
much more portable.
> I've gotten burned by this way many, many times, which is why I include
> the generated configure script with respect to *my* development system.
And more power to you if that's what you want to do. But I've heard all
these arguments over and over again for years, and I consider generated
files in version control to be a huge problem and a major irritation for
developing software. So I'm not going to do that. If you can tolerate
it, feel free to do it.
> But if I forced people to run the autoreconf on every git checkout, they
> would end up losing all the time anyway...
I've had very few problems with this, and mostly it has led to people
submitting useful patches for that part of the build system. So I'm going
to stick with what I'm currently doing. :) People who don't want to deal
with this can just use tarball releases. There's nothing wrong with using
a tarball release; that's what it's there for.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>