Re: [Indic-computing-devel] Re: debian toolchain question.

[Cherry G. M. <ber...@ya...>]

 >>>>> "alok" == alok kumar <alo...@so...>
writes:

alok> Hi Cherry, This is interesting, particularly
since I haven't

[...]

alok> Would this indic-doc-toolchain.deb file be such
that deb2rpm
alok> works on it?

Hmm.... I'm really not sure. I'm made the debian
packages by following
instructions from the debian.org site. I guess there
is no particular
reason why they shouldn't work with deb2rpm, if
deb2rpm works with
other debian package. Perhaps you could try it and
send a report ?


>> II) _______The_src_makefiles_______ The Makefiles
within
>> doc/share/mk assume a FreeBSD directory layout.
This is quite

[...]

>> trying to make it portable would bloat the Makefile
code a lot
>> (writing wrapper variables, #ifdefs etc. )

alok> What is the cost of having a huge makefile? Does
it o
alok> increase build time?

That one is for Koshy. I'm a newbie with BSD make.

alok> o reduce readability ?

IMHO, yes. We don't want debian developers groking
through BSD
"clutter" and vice versa. Not looking for a flame war
here, of
course.



>> On the other hand, if we have a maintainer <->
upstream

[...]

>> be tweaked and debugged to its best.

alok> The way this currently happens is - Koshy makes
the changes,
alok> as and when required, for everything to work on
FreeBSD. And

[...]

alok> automate them? Actually, yes, by the cvs commit
logs one can
alok> make out what changes would be relevant for the
other
alok> branches. So this could be workable. The
questions that
alok> arise are, o how many branches do we keep? One
for debian,
alok> another for RH, one more for mandrake, not to
forget
alok> win*/cygwin o how do the changes in one
branch(not
alok> necessarily the bsd one) get merged to the
others?

Yes, why not ? Look at the successfull Open Source
distributions out
there: NetBSD, FreeBSD, Debian...... Each of them has
a
Maintainer <-> Upstream working model. Each of them
has a bug
tracking system with which specific bugs are allocated
to specific
maintainers. The whole issue here is how to delegate
responsibility. If people volunteer to offer working
packages, update
them continually, document them, and contribute their
additions back
to the upstream authors, the quality of the whole
package improves. If
OTOH volunteers offer features, the responsibility of
code management
is divolved among many people, and as the saying goes,
"everybodys'
job, is nobody's job". Take a look at the number of
individual
maintainers of the linux kernel, each person
struggling with enormous
code bases, and being less able to give effective
attention to quality
( remember the Dec 24th attack on Debian servers ? )
to get a feel for
what I'm saying.

Since we're using CVS, we could merge the HEAD branch
periodically,
with the port branch, and work out issues as and when
they come. But
AFAICS, there really is not too much work to be done
on the
doc/share/mk tree. We should get it up and running,
and focus
attention on other crucial areas like OS Image
development etc.

Best,

Cherry.
-- 
ch...@sd...
SDF Public Access UNIX System -
http://sdf.lonestar.org


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus