[153] in athena10

home help back first fref pref prev next nref lref last post

Re: /svn/athena r22816 - in trunk/debathena/meta: .

daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Apr 7 10:38:25 2008

From: Greg Hudson <ghudson@MIT.EDU>
To: Timothy G Abbott <tabbott@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <Pine.LNX.4.64L.0804041825090.19321@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Mon, 07 Apr 2008 10:37:32 -0400
Message-Id: <1207579052.5912.20.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Mon, 2008-04-07 at 01:52 -0400, Timothy G Abbott wrote:
> I'm not sure exactly what the relationaship between this package and 
> debathena-standard (etc.) is supposed to be, but I figured I should point 
> out:

debathena-cluster-software is likely to be expanded to contain pretty
much any native package someone requests be available on cluster
machines.  For example, http://diswww.mit.edu/menelaus/release-77/5904
contains some requests from Alex Prengel.

I don't want to couple this set to debathena-standard or
debathena-workstation because people who want Athena-like machine
behavior don't necessarily want multiple gigabytes of software just
because someone wanted all of that stuff available on cluster machines.

I also didn't want to tightly couple it to debathena-cluster (which
doesn't exist yet, but is the name of the metapackage I expect to
install on Debathena cluster machines), because someone might want to
install this alongside debathena-workstation without turning their
machine into a self-administering box.  debathena-cluster will depend on
debathena-cluster-software, of course.

So the basic Chinese doll of metapackages is:

  debathena-locker: Access to Athena locker software.

  debathena-standard: Athena-like configuration without modifying user
logins or the graphical environment.

  debathena-login: Use Hesiod, Kerberos, and AFS homedirs for user
logins.

  debathena-workstation: Cluster-style graphical environment.

  debathena-cluster: Self-administering workstation including
IS&T-maintained software set.

We'll still have the equivalent of a PUBLIC=false Athena machine with
debathena-cluster installed, but I think dropping down to
debathena-workstation will be attractive to people who don't want a big
disk footprint or want to maintain a higher level of control over their
machines.  Particularly if they don't want to bloat their machine with
the cluster software set.

> debathena-standard depends debathena-clients depends debathena-hesiod-config depends hesiod

Why does debathena-hesiod-config depend on hesiod?  All hesiod contains
is the "hesinfo" command, which is totally unnecessary for setting up
the system Hesiod configuration.

> Also, you may want to use debathena-debian-dev or debathena-build-depends 
> rather than build-essential; currently debathena-workstation depends on 
> debathena-build-depends.

I only want to be depending on native packages in
debathena-cluster-software.  The goal of that dependency is to be able
to build random software on the net (including random GNOME software),
not Athena software.  "X class of machine should be able to build Athena
packages" is a fine dependency for one of the five metapackages listed
above, but it's not fodder for the cluster software set.



home help back first fref pref prev next nref lref last post