On Sun, May 03 2009, Bernhard R. Link wrote:
> * Manoj Srivastava <sriva...@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?
In that case, having the sources cluttered with autotools
changes is pretty bad. I would much rather unpack their sources, and
run a diff -uBbwr between two source directories. In that case, not
having the autotools in the packages is nicer.
> 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).
You are not really about collaborating with them, you want
really a quick diff. For that, I suppose an uncluttered package source
is good.
>> > 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.
I see adding autotools files and cluttering up a user running
diff a bad thing, similar to (but perhaps different in degree) storing
away a private gcc install in the binary.
manoj
--
Television has proved that people will look at anything rather than each
other. Ann Landers
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
