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

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

Re: [Gnu-arch-users] feature plans from over here....


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] feature plans from over here....
Date: Wed, 18 Aug 2004 18:11:38 +0100
User-agent: Mutt/1.5.6+20040803i

On Wed, Aug 18, 2004 at 10:11:57AM -0700, Tom Lord wrote:
>     > > >   ~ allow other directories
>     > > >
>     > > >     Of course, the well known thing we need ---
>     > > >
>     > > >     % tla --params DIR
>     > > >
>     > > >     to use DIR instead of ~/.arch-params
> 
>     > Actually, once you get around the initial repulsion, hacking $HOME is
>     > quite simple, effective and unavoidable to some extent. For example, I
>     > will not make the pyarch test suite rely on the correct handling of
>     > --params. We have recentley seen a regression in the support of
>     > "update --dir" so a regression in --params does not seem impossible).
> 
> 
> The problem is that tweaking $HOME effects other subsystems as well.
> E.g., is it really certain that you want all of your hook scripts
> invoked by tla to use the altered $HOME?   

And in a specific example, I want buggoo to be able to move
.arch-params, because it's going to take over it and generally muck
about with the namespace and configuration, while still using the host
account's .gnupg. There are several approaches to the problem, but the
only one which makes any real sense is something like tla
--params. Particularly when you throw in the desires for (a) multiple
instances in a single account, and (b) one instance that is portable
across multiple accounts (I'll stuff .arch-params into the bug tree).

Anything that drives tla as a long-term slave in this manner will
likely want this feature. Short-term things, like the aforementioned
test suite, don't really need it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

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