some try-ark suggestions

Jonathan:

Okay, this is getting really weird.

I checked out the latest stuff from CVS.  I reviewed all of my configuration
customizations.  I reattempted try-ark.

Result:  the gzip pieces were built, but no rsync or textutils.

Digging:

I see this error message in the try-ark output:

file doesn't exist: /usr/local/src/rsync-2.4.6.tar.gz

But, if you recall, yesterday I was unable to build gzip because I had a
gzip-1.3.tar.gz file in my open-src-dir:

file doesn't exist: /usr/local/src/gzip-1.3.tar

So, seeing that error message yesterday, across the board I unzip'ed all
tarballs downloaded from the recommended places, thinking that in all cases
unzip'ed tar files are required.

Except that is *not* the case, and now, no rsync or textutils.

After several more trials, and responding to the various error messages, I've
found this combination to work:

[root@localhost src]# ls -l
total 5028
-rw-r--r--    1 berto    berto     1064960 Jun  9 08:31 gzip-1.3.tar
-rw-r--r--    1 berto    berto      332269 Jun  9 08:34 rsync-2.4.6.tar.gz
-rw-r--r--    1 root     root      2170104 Jun 12 08:10 textutils-2.0.14.tar.gz

Now, finally:  JOY!

But this is screwy.  Success or failure appears to depend on getting just
the right mix of .tar, or .tar.gz.

More digging:

[berto@localhost package]$ pwd
/home/berto/ark/ark/sidai/package

[berto@localhost package]$ egrep "\.tar|\.tgz|\.tar\.gz" gzip.xml
  <param name="PKG_TAR_FILE">!'@package:ark-dirs:PKGS_SRC@/%s-%s.tar' % (pkg_name,pkg_version)</param>

[berto@localhost package]$ egrep "\.tar|\.tgz|\.tar\.gz" textutils.xml

[berto@localhost package]$ egrep "\.tar|\.tgz|\.tar\.gz" rsync.xml
egrep: rsync.xml: No such file or directory

???

These apparent inconsistencies are more than my feeble brain can comprehend.

I think there is a very real problem here.  You can't depend on the user
having just the right mix of package file formats.  Either you must
strictly require the package-x.y.z.tar.gz format across the board, or
better you code for every reasonable possibility.

In other words, if the user has, say, the following

-rw-r--r--    1 berto    berto     1064960 Jun  9 08:31 gzip-1.3.tar
-rw-r--r--    1 berto    berto      332269 Jun  9 08:34 rsync-2.4.6.tar.gz
-rw-r--r--    1 root     root      2170104 Jun 12 08:10 textutils-2.0.14.tgz
-rw-r--r--    1 berto    berto      287239 May 21 11:19 bison-1.25.tar.Z
-rw-r--r--    1 berto    berto      380995 May 21 11:19 flex-2.5.4a.tar.bz2

the Arusha code should take this all in stride and just Do the Right Thing
in all cases.

Does any of this make sense?

Oh, I repeat my assertion that you need to embellish the "Test drive with
try-ark" section of the try-ark1.html page with additional commentary.
On the face of it, the demo is underwhelming.  I mean to say, great, (after
much work!) I've got Arusha to build the gzip, rsync, and textutils packages.
(It's not immediately evident where these build to.)  But how is doing it
this just-concluded Arusha way better than my doing it the old-fashioned
way?  What have I gained here?  What is sidai's value-added?  I've just
witnessed the build portion of "build/install/deploy/reveal".  What would
I now do to effect an install, a deploy, a reveal?  That's the potentially
Cool Stuff here, not the builds (unless sidai policies have imposed some
non-standard build options).  Please elaborate.

More constructive criticisms, I hope.

Berto

-------------------------------------------------------------------------------
Robert Osterlund, Unix Systems Manager                [email protected]
Grad School of Business, U of Chicago                       phone: 773/702-8898
1101 E. 58th Street, #309, Chicago, IL 60637, USA             fax: 773/702-0233