Re: [MacPerl] CPAN

["Paul J. Schinder" <schinder@leprss.gsfc.nasa.gov>]

At 9:31 1/15/97, Chris Nandor wrote:

}At 8:52 1/15/97, Paul J. Schinder wrote:
}>I take it that Andreas software assumes a .tar.gz, or does it accept other
}>formats?  How smart is it?  It seems to me the simplest solution would be
}>for you or anyone else wanting a MacPerl package in CPAN to create a two
}>item .tar.gz, a README and the .sit.hqx.  His receiving software could be
}>modified to put the .sit.hqx (we *really* should be using .sit.bin) and the
}>README uncompressed into CPAN rather than the .tar.gz file itself.
}
}Interesting.
}
}1.)  No, we should use .hqx.  .bin is too unreliable.  I know it is
}smaller, but too many people have had problems with it for me to condone
}its use.  Just my opinion.
}2.)  But if we are going to bother to .tar.gz it anyway, why create the
}.sit.hqx?  Almost anyone who uses MacPerl can get at .tar.gz files, simply
}because you need it to get at everything else in CPAN.

Because of 1.  If you think dealing with *.sit.bin is too hard for the
average MacPerl user, imagine dealing with .tar.gz.  I agree that
*.hqx causes less trouble than *.bin, because it's almost impossible
to screw up, but if they can get .tar.gz done right, they can
certainly get .sit.bin done right.  The two major Mac ftp clients
autodetect MacBinary out of the box, and it should certainly be
possible to get the http front end to CPAN to spit out the MIME type
commonly used for MacBinary before sending the file.

OK, now I understand the issue.  Andreas has automated receiving
software to deal with CPAN submissions.  It can't deal with the most
common Mac compression format because it's proprietary and there are
no Unix translators available, and I assume he doesn't have access to
a Mac to do the translation.  (Does anyone know if Compact Pro format
is propietary?)  It's not a matter of checking the contents, his
software simply looks for a README and extracts it, placing it
alongside the compressed software archive in the proper place in the
CPAN archive.  The README should have Unix end-of-lines, but nothing
else needs to.

One solution is .tar.gz, which is certainly not a problem for me or
anyone else with Stuffit Deluxe, and is straightforward even if you're
using the free Suntar and MacGzip, as I used to.  But it's not a
common Mac format, at least not until the end of this year.  One must
remember (or have Internet Config set to tell the apps that consult
it) to download in binary mode.  It's fine with me, but if you think
*.bin will cause people problems and shouldn't be used, realize that
*.gz will cause even more.

The other solution is to tweak Andreas' software so that it can
automatically insert a Mac archive in the common format (*.sit.hqx)
into CPAN.  I've suggested one way, but there may be better ways.  My
way puts the onus on the author to get his README into Unix format
(trivial with the major Mac text editors) and to create a .tar.gz and
requires Andreas' software to realized it should extract *.hqx and put
*that* rather than the .gz into the archive.  I would guess this is
feasible on both ends.


--------
Paul J. Schinder
NASA Goddard Space Flight Center,
Code 693, Greenbelt, MD 20771 USA
301-286-1550
schinder@leprss.gsfc.nasa.gov