Re: squishing install and deploy dirs together

[Will P. <pa...@dc...>]

Hi, Jim et al. -- Taking your questions/comment out of order:

> 3.) Am I out of my mind?

No :-)

> 1.) In this context, are there reasons to keep install and deploy 
> distinct?  If so, what?

Probably not (i.e. your analysis is sound).

The install/deploy/reveal thing is *not* supposed to be an all-knowing
everyone-should-do-it-this-way thing.  It's just one way.  The more
common "just stick it in /usr/local" -- make install prefix=/usr/local
-- should also be possible.  Or what you want to do.

For the install/deploy/reveal thing, the steps (and what they get you)
go like this:

* You tell the software at build time that it is in the deploy place; i.e.
  make install prefix=$deploy_dir [whatever that is]

  Because the deploy_dir is traditionally version-specific, you can have
  many versions live at once.

* The business of copying over what you've built to the install area
  (again version-specifically) is so that you have a single golden copy
  per type of machine with which you can do clever things.

* We now deploy the golden cop{y,ies} onto individual machines.  If an
  individual machine has a big disk (they all do now, but they didn't
  when ARK started...), you can deploy by taking a copy.  Or you can
  deploy by symlinking.  Or whatever you like, machine by machine.

  Another thing you can customize is what set of versions of the
  software each machine sees.  So, for example, the Team A machines
  might have an old version; but the Team B machines would have all
  versions.

* Finally, revealing: This is creating a symlink or something in the
  users' PATH so that they can run whatever it is.  My experience is
  that asking users to meddle with their individual PATHs constantly is
  just a recipe for disaster.  So, for example, we just say "put
  /our/bin near the front of your PATH" and declare victory.  Revealing
  puts the right links to the right versions in /our/bin.  Again, it can
  be varied machine by machine (if you're crazy enough to do that).

If you don't want any of that stuff, don't do it that way.

> 2.) Do you have guidance for me in terms of the general approach to 
> making them be the same?  (i.e, Where do I hack?)  Is this going to be a 
> big job or a small one?  Has anyone done something similar that would be 
> useful as a starting point?

I am not aware of someone doing something similar.  I hope it would be a
pretty small job.

Assuming you're sucking on the Sidai methods (i.e. in
$ARK/sidai/package/{GNU,ALL}.xml), I'd proceed by...

* cutting out unnecessary methods -- so, for instance, if you want
'reveal-bits' to depend on 'install' rather than 'deploy', just change
the dependency in the 'reveal-bits' method.

* simply change the method shell scripts to do what you want

I'd do them in place (for simplicity).  Afterwards, you can move your
changed files out of the way, re-'cvs co' the sidai stuff, then use the
diffs (which I would expect to be modest) to fashion some .xml for your
own team that would then override the sidai stuff and do what you want.

Hope this helps,

Will