Here are our responses to reviewers' comments:

> Referee 1 *******************************************
> 
> This paper discusses Netbuild, which is a tool that can automate the
> processing of installing and configuring software libraries. Netbuild
> works on heterogeneous platforms. The paper describes the basic
> architecture of Netbuild and the initial implementation.
> 
> As a software tool, Netbuild would be a welcome and useful addition to the
> application programmers toolbox. Programmers spend an inordinate amount of
> time searching for and installing software libraries. Such searches and
> installations are often met with frustration as most such libraries do not
> install, nor are correctly configured in an easy manner. If Netbuild could
> overcome such frustration, it would be a truly useful software tool.
> 
> Details in the paper are "light". The outline that is presented of
> Netbuild seems reasonable. 

> One thing I couldn't quite figure out if there
> were any language dependent issues? Will Netbuild work for C++ software
> libraries that extensively use templates? What about mixed language
> software libraries, will Netbuild install and configure different languages
> equally as well?

> Because the paper discusses an "initial implementation", it is difficult to
> assess Netbuild's effectiveness. It would be great if the authors could
> update the project to include any initial results.
 
 
> Referee 2 *******************************************
> 
> E: Referee Comments (For Author and Editor) ------------------
> 
> Claims in the paper like "In General the more libraries on which a
> program depends,t he fewer environment it can run on" are largely
> unsubstantiated though understandable. There is no data given
> substantiating such claims. E.g. I ran in to problems where a
> program consisted on a large number of libraries 10 and it was more
> portable that a program that was only dependent on one library.
> The point I believe one needs to make is that portability
> statements must be derived from the libraries.

We were trying to make a statement about the administrative difficulty
of installing large numbers of libraries on platforms that are maintained 
by different sets of people, not about program portability in general.
We have reworded this statement in an attempt to make this clearer.

> In Section C. Describe more about the efforts that are underway.
>
> Also the section implies that Net build is not stable, which would
> be bad for this journal issue.

NetBuild is definitely still a work in progress.  For now, the collection
of NetBuild libraries is maintained "by hand".  Our experience with 
this kind of maintenance in the context of other projects - where
the libraries were manually downloaded - has demonstrated that it is not 
adequate to serve users' needs.  We do not wish to make NetBuild generally 
available until we can continuously maintain its libraries.  We are 
awaiting funding for Netlib which will allow us to do this.
 
> Section Searching for local libraries
> 
> It is not clear who one deals with dependencies in
> dynamically linked libraries.
> 
> assume I compile a dependent on b with X
> and b is compiled with Z that is incompatible with X
> can that be done?

We tried to make this clear in the Goals section of the revised
paper.  Netbuild cannot remove incompatibilities between different
libraries.  At best it can recognize them via its constraint expressions.

> The attributes introduced in section "Identifying target ..."
> imply that a weight must be imposed on this attributes, probably to
> build a weighted sum. No analysis is provided on what would be
> best, if this is a good idea, or whay and whay not certain
> attributes are chosen.

We did not make this very clear in our original submission, but 
we were not using weighted attributes.  Also, we have changed the
candidate selection algorithm since writing the original draft.
Our revised submission reflects the current candidate selection
algorithm, and provides an example of constraint expressions
for several different implementations of a library. 

> The use of cgi and a global database may not be such a good idea,
> as it causes a lot of delay. Why not define a service-based on other
> more advanced technologies. later in the paper this is displayed as
> a good part, but it seems to me this is more a "hack" than real
> motivation.

We tried to address this briefly in the revised version by stating
that multiple servers are possible and the client is capable of 
choosing from several search engines.   However, this technology is
not specific to NetBuild and describing it at length would detract
from this paper.
 
> What short comings does the tar format have, no explanation is given.

We could have listed them, but again, this would detract from the
message of the paper.  Since we are discarding the tar format anyway, 
we decided to just rewrite that section to avoid mentioning it.

(in a nutshell,

  the chief benefit of using tar is the ability to use existing
  tar commands to assemble libraries by hand.  however there are 
  multiple versions of tar with slight differences between each,
  and we would have to provide tar extraction code to work with 
  each of them.  it would be difficult to be sure that we had
  covered all of the variants.

  also, using the target system's tar command to extract files
  introduces security holes, since on many systems tar files can 
  specify complete path names, or relative path names, which 
  could cause existing files to be overwritten.
)

 
> Section NetCompile:
> 
> How can I express the dependencies of the application for a
> particular target platform. General statements are made,
> but they are not substantiated with an example or a better
> explanation.

we supplied an example in the revision.

> Section Distribution ...
> 
> How can one prevent malicious libraries, wouldn't every
> library need to be signed?

yes.  but netcompile does sign the libraries.

 
> Section Related Work
> 
> A more precise description of what you want to "borrow" is
> in order.

how should we say that we have looked at their code, and gleaned
ideas from it, but not copied it?  instead in the revised draft
we just mentioned their work as related work without saying we
borrowed from it.
 
> Section Status ...
> 
> we would like to see a discussion about the various
> data models. Unfortunately, this is not described here.

we should not have described this as "various data models"; rather,
it is a single data model (per-platform) that we are developing
and modifying based on our experience.  we've reworded this
in the revision.

> Apply the technology to at least one other code example not
> just Netsolve

??? not sure what he/she means by this, since we didn't mention netsolve.
 
> F: Presentation Changes
> 
> all over:
> 
> During the print the following errors were obvious a , is
> followed always by the next letter and a blank e.g. Internet,a
> nd instead of "Internet, and"

our guess is that this is a problem with fonts on the reviewer's
system.  we haven't observed this when viewing the document with 
either acrobat reader or xpdf.
 
> Section D.
> 
> A diagram necessary to explain architecture/usage.

two figures and accompanying text have been added to explain this.
 
> Section 3. paragraph NetBuildTool.
> 
> This whole paragraph needs rewriting. The explenation of shims
> could be better

we have supplied a figure and text to illustrate the operation
of the shims.

 
> Section 3. General
> 
> It is not clear if the information is stored in a global
> directory or not.

this should be clearer now with the additional text in section 3.1.

 
> Section "Authenticaticity ..."
> 
> Do not use a colloquial phrase such as the sentence with
> "okay" in it this is not very precise language for an
> academic paper.

this has been reworded.

 
> Referee 3 *******************************************
> 
> 
> Referee Comments (For Author and Editor)
> 
> NetBuild builds on the successful repertoire of tools that have been
> developed
> at the University of Tennessee. It automates many of the tedious details
> that
> are involved in remote access of software libraries.

 
> However, the presentation makes it clear that NetBuild is little more than
> an IMakefile system that is grid-aware. Some of the goals of this project
> (e.g., "automate the process of selecting ... software libraries over the
> Internet", "automate the construction of such libraries") are quite lofty.
> But the superficial manner in which these topics are "solved" (by NetBuild)
> indicate that the researchers have a very incomplete understanding of the
> issues involved. For instance, selection of appropriate software is not
> merely a matter of tagging libraries with architectural parameters and
> selecting them. John Rice and colleagues at Purdue have been trying to
> design such automatic algorithm selection systems for the past 20 years, and
> the problem is one of the most open issues in numerical computing. Please
> see the work by this group for more holistic approaches to this problem.

we have added text to the goals section to clarify that our goals are
more modest than automatic algorithm selection and other problems which
this reviewer recommends that we address. nevertheless, we believe that 
NetBuild will be very useful even without solving that problem.