[2131] in athena10
Re: the impact of each metapackage
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Wed Apr 8 21:47:04 2009
Cc: Debathena Trac <debathena@mit.edu>
Message-Id: <03DB9E0D-89E6-41DD-86BF-8AA05BF60206@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
In-Reply-To: <alpine.DEB.1.10.0904081608470.28854@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 8 Apr 2009 21:46:33 -0400
> Maybe I'm misunderstanding the intention, but I don't think that
> advertising debathena-clients available as a "don't mess with my
> system"
> alternative to debathena-standard means that we should not be very
> careful
> to limit the complexity and potential for breakage caused by
> debathena-standard, which I suspect will be the level of integration
> desired by most users not using AFS home directories (i.e. on their
> laptops or personal servers).
I also had assumed that debathena-standard was supposed to be
minimally invasive. However, the discussion surrounding -tex-config
revealed that people had differing expectations of just how invasive -
clients was supposed to be. Rather than having these arbitrary
expectations, I felt it best that we codify just how invasive each
package was supposed to be. In vague terms, it seems like debathena-
standard is "Please don't mess with my system." and debathena-clients
is "No, really, don't mess with my system!"
I'm not saying that defining debathena-clients as "don't mess with my
system" means that we should let -standard run amok. However, I'm
suggesting that we establish debathena-clients as a bare minimum level
of invasiveness, and debathena-standard is slightly more invasive by
virtue of debathena-printing-config, for example (which is already in -
standard).
> I think it would be helpful to consider this broader issue in the
> context
> of the individual proposals that have come up that effect it.
That's probably best. I was trying to avoid that, because I didn't
want to harp on specifics, but defining this in general terms is too
confusing, I think.
> The questions that I can recall that spawned this discussion were:
>
> (1) debathena-tex-config
> (2) changing /etc/hosts on Debathena machines
>
> I don't think that this is complete, though. Remind me what else
> there is?
There was a similar discussion when we were debating whether caching-
namesever should go in the new -workstation, IIRC>
-Jon
