gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Re: tagline robustness


From: Tom Lord
Subject: [Gnu-arch-users] Re: tagline robustness
Date: Wed, 27 Aug 2003 08:28:20 -0700 (PDT)


    > From: Miles Bader <address@hidden>

    > Tom Lord <address@hidden> writes:
    > > The original architectural conception here is of inventory being
    > > reasonably (and usefully) separable from the rest; mkpatch/dopatch
    > > being similarly factorable-outable (but layered on inventory, of
    > > course); and then patch-logs, the namespace, and the core archive
    > > protocol being a layer on that.

    > I've noticed this, and wondered whether it had something to do with the
    > original implementation being via shell-scripts -- certainly this
    > property of arch has made my own little shell scripts often very easy
    > to write.

It's hard to go back and dissect my thinking this much later but:

1) The layering/software-tools-approach I described came first.
   For example, I briefly considered implementing it in something
   SCSH-like first -- but with the same architecture.

2) The shell-based implementation helped to keep the architecture
   "honest" -- it's hard to _not_ stick to a software-tools approach
   if you want to keep your shell code clean.   Conversely, it's
   harder now, with tla, to keep the architecture clean.

3) A purist might argue that the point at which things started going
   to hell was when `inventory' was changed from a shell script that 
   invoked `find' (with several dozen arguments) to a stand-alone
   program that did it's own traversal.   The current plans for
   generalizing =tagging-method really drive that point home: it's 
   already the case and soon much more so that you _can't_ compute 
   a tree inventory other than by using this very specific, highly
   configurable tool.

   I'm not sure that could have been avoided.  _I_ would have thought
   "Ok, sure, a very limited `inventory', such as could be implemented
   with `find' and `sed', really suggests using an enhanced discipline
   about how you layout your source trees -- but that's a good thing."
   As you can see from list archives, though, it's too much of a
   religious issue with too many people.


[other replies separately]

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]