Hi,
I think this message is likely to lead to a mostly useless
flurry of messages, but then we have not had a mostly useless heated
discussion on this topic in a few months.
On Sun, 18 Feb 2007 13:18:25 +0100, Marc Haber
<[EMAIL PROTECTED]> said:
> On Thu, 15 Feb 2007 12:28:06 -0600, Manoj Srivastava
>> We are packagers to start with. Yes, we are more than glorified
>> packagers, but our primary value add is packaging and systems
>> integration. Seems like the ideal candidate would find learning
>> how packages are put together and integrated a fun activity.
> I tend to learn better by watching tools at work. Thanks to free
> software, tools[1] are available to watch tools.
While learning by example is fine, there is no substitute for
actually doing the work. You can buy all the howto-be-a-carpenter
books, but until you try building a project ... I also find that
skimmin through computer language text books does not compare to
actually writing code.
>> I personally find hand crafting my packages more satisfying and
>> more fun than just using helper packages. Your mileage obviously
>> has varied.
> Obviously. Your approach sounds like not invented here, mine like
> code reuse.
You know, we seem to have reading comprehension issues here.
My fondness of the training exercise to learn the underpinnings of
the build process "once" does not lead to lack of code reuse -- first
flaw in your logic.
Second, You are assuming there is no abstraction or code reuse
if you do not use helper tools. Neither of these assumptions is
justified, or indeed, correct, for my build systems.
Next, there are tradeoffs involved:
a) helper tools imply added dependencies; any backward incompatible
change in your helper tool might render your package unbuildable
or buggy.
b) You have to wait until your helper package implements a new
packaging improvement, or policy change
c) A helper package has to be general purpose, and might not be as
efficient or correct as a hand crafted solution.
d) Not using helper packages in the build makes it possible to build
on a non-debian box, or for a person from a different UNIX/Linux
background to grok what your build process is doing.I have found
both these characteristics beneficial.
e) By not delegating the work to someone else, I retain a deeper
understanding of the nitty gritty details of how my packages are
put together, with, in my opinion, less of an expenditure of
effort.
f) With the abstraction layers I have in place, I find I need to put
in minimal effort for creating a new package, or maintaining a
current one; and I gain the benefits that helper packages are
supposed to provide one.
If not jumping not he latest fad (yada, cdbs, dbs, dpatch) is
NIH, the color me guilty.
manoj
--
QOTD: Silence is the only virtue he has left.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
