Re: Source-Depends? Autoreconf?
* Manoj Srivastava <srivasta@debian.org> [090503 01:24]:
> I wold like to say that I do not really see the Degbian source
> package as a primary mode of development communication between Debian
> and the downstreams, as it is strictly a snapshot, and loses too much
> history. I think that people deriving code based on lines of
> development I have in my packages will be better served by using a
> distributed VCS; and collaboration and feeback would be far easier.
For a close colloboration and joint development having history and
anything that brings the changes nearer to upstreams (having branches
in upstream's centrel VCS, or using the same distributed VCS as upstream)
is of course the way to go, and having additionally something with
history is of course always good.
But whenever I wanted to look around what other distributions did with
one of my packages, I really started to hate the "a VCS is everything
that is needed" approach. Getting lost in the CVS directories of some
*BSDs, having to deal with all kind of different VCSes like arch, bzr,
subversion, or whatever the particular distribution decided to
standardize on, having things differently everywhere and jump through
hops to just get what I'm intrested in: What is their current state?
What changes have they applied?
Then often having things practically forked, as their VCS has history,
but does not group changes. (Which if from that point of view not really
easier than having just a single monolythic patch, with the only
difference that it took hours to get that patch and with even more time
you could learn how you can see when each line was added).
> > Also assessment of external factors plays an important role. Several
> > years ago, autotools changed quite rapdily and
> > disruptively. Robustness was an important reason to not run autotools
> > while building. Now this has changed, so running autotools at build
> > time is often considered the best solution, as it causes clean diffs,
> > well-tested build paths and easy maintanability. (Though it still
> > depends on the actual case. Very small changes, massively outdated
> > uptreams and/or usage of strange corner-cases of autotools can still
> > make something else better depending on a wide range of factors).
>
> The same might be true for any other component in the tool
> chain, no?
Of course it is. Nothing special about autotools here, except perhaps
that you more often have the choice. You cannot add a compiler to your
package (so all you have to choose from is using the default compiler or
forcing a specific version and build-depending on that), while autotools
make it possible to have the build system there. And once you have the
choice, you need to decide what is best.
Hochachtungsvoll,
Bernhard R. Link
Reply to: