[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Handling of (inactive) Debian Accounts


        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
<mh+debian-devel@zugschlus.de> 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
 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.  

QOTD: Silence is the only virtue he has left.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: