Re: Library dependencies in Arusha

Joel S writes:

> Some interesting problems cropped up when I tried to omit the C
> compiler from a host running a web server.

(Indeed :-( )

> Problem 1:  Arusha constraints do not capture the requirement that
> Python deployment needs libraries installed by gcc.

Well, virtually everything compiled by gcc needs libgcc_s.so
(or whatever), and anything C++-ish needs libstdc++.so.

The way I would go about trying to conform with good practice
is to have one gcc package, but varying <deployment-spec>s;
something like (see sidai/package/gcc.xml) :

  <!-- for compiler-less machines ("servers"?) -->
  <deployment-spec>
    <constraint><host-spec>.:server</host-spec></constraint>
    <table><entry name="*">
  @TYPE@=manifest
  ^lib/lib.*\.so copy * * 755
  .              none
  </entry></table></deployment-spec>

  <!-- default -->
  <deployment-spec><table><entry name="*">
  @TYPE@=manifest
  ^lib/lib.*\.so copy * * 755
  .              link
  </entry></table></deployment-spec>

In fact, I might arrange to do this game for *all* library-like
packages.  (At least in the verilab2 files, I have started
to put in prototypes of sidai:library [see zlib--1.1.4, for
instance] -- that might be the right place for the common
(magic) deployment-spec.)

> Problem 2:  Since Sidai policy tightly controls the library load path
> at compile and run times, the configuration files should capture the
> critical dependency on specific versions of packages.
> 
> For example, ldd showed that Python depends on libraries installed by:
>     zlib--1.1.4
>     expat--1.95.5
>     openssl--0.9.6g
>     readline--4.3
>     python--2.2.2
>     gcc--3.2
> 
> If any of those packages were updated (as when zlib was changed to fix
> a security problem), Python should be recompiled.  Many packages
> probably should be recompiled, too.

I am well aware of this problem, and have not settled on
what the right thing to do is.  (As often as not, I kinda
snoop around and do something by hand. :-)  One option would
be to have a script that looks through the persistent state
info (/d/ark-state/*/...) and lists the packages/things that
have a dependency on the stated package thing, so...

   arkdepls package/zlib--1.1.4

would list all of the dependees, and

   ark-invasive `arkdepls package/zlib--1.1.4`

would re-do all of them.  I doubt it's quite that simple,
but...

(BTW, I agree that the non-GCC dependencies need to be
explicit in the ARK config files.)

> Problem 3:  We need to know which version of gcc compiled each package,
> but gcc-wrapper hides that information.  ...

Maybe this should also be stashed in the state info?

> Problem 4:  Although Sidai configuration files carefully control the
> path of each command, the arkcmd script looks for Python on the shell's
> search path.
> 
> The arkcmd script does not honor the configuration choices defined in
> team/host/ALL.xml:
> 
>     <PYTHON><string>@team:ark-dirs:LOCAL@/bin/python</string></PYTHON>
>     <PYTHON-BOOT>@team:ark-dirs:ARK_BOOT@/bin/python</PYTHON-BOOT>

Er, I agree with you, but there's a kinda chicken-and-egg
thing going on...  Ideas, anyone :-?

Will


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.