Re: [MacPerl-Porters] Identifying Ported Modules

["Paul J. Schinder" <schinder@pobox.com>]

On Tue, 11 Jan 2000 22:49:34 -0600 (CST), Matthew Langford wrote:
>
>
>On Tue, 11 Jan 2000, Paul J. Schinder wrote:
>
>> On the contrary. I think It's a little harder for a MacPerl user to mess
>> things up, because MacPerl comes with more things in the "core" than in
>> the standard Perl distribution. 
>
>Can you give me an example of installing a CPAN module which would break
>something under Unix, but does not under MacOS?  I can think of several
>situations which break under MacOS, but not under Unix:  port, requires
>binaries, bundle which almost certainly has both, etc.

I can give you a practical example of something that *did* break things
under Linux, although in this case it would also have broken things under
MacOS. Compress::Zlib 1.06-1.07 had a bug which caused weird things to
happen when I installed it on my Mac running Linux. So I had to back down
to Compress::Zlib 1.05. Note that I had to go to extra effort to do this,
because, while you can uninstall a Perl module, you can't "revert to
previous state" with the Makefile from a new distribution. During the time
I was backed down, a new CPAN.pm came out. When I mindlessly typed
"install Bundle::CPAN", I found myself frantically typing ^C a few seconds
later as it started to "helpfully" bring my Compress::Zlib up to date.

I was protected from this under MacPerl because I *can't* build XS, so of
course I didn't even try installing Compress::Zlib. Mostly that's sheer
laziness, since I believe the technique for building with MrC is now
worked out.

On a large scale, any module which passes its tests and isn't in core Perl
but is in core MacPerl will be harder to fix under Unix than MacOS.
libwww-perl at one point in the recent past had an ftp bug that caused ftp
to simply not work. A MacPerl user would have an easier time fixing this
by reverting (easiest way was simply to rearrange @INC, which is exatly
what I did at one point).

>
>As I understand it, no one wants to fix these obvious breaking points,
>because things can also break under Unix, maybe even more often.  Hmm.
>The other solution, I'm told, is to get rid of the features entirely.

No. No one wants to spend the time to fix a problem which is basically
just part of using a computer. I feel there are more important things to
be spending my time on. Personally I see a few earthquakes coming in
regards to MacPerl. I'd rather wait to see what mountains have been raised
and cast down before flattening a few anthills.

[snip]

>
>Not only that, but you significantly understate what is required.  You
>must open the Makefile.PL, and perhaps other files, to decipher what must
>be pulled from where.  For example, do you leave or yank Entities.pm,
>HeadParser.pm, TokeParser.pm, LinkExtor.pm, and Filter.pm from HTML::?  
>On top of that, you may need some knowledge of Makefiles, MakeMaker, and
>the MacPerl directory structures.  This is too much to ask of _everyone_
>who uses CPAN.

Good Lord, no,. There's a MANIFEST, a .packlist (at least on Unix), and I
also knwo where files would have been installed and how to use find(1). On
MacOS, I know how to use Sherlock (ask Sherlock to find all files in
site_perl which have been installed in the last 10 minutes, which I think
it can do. If not, the last day, which I *know* it can do), I know where
the files go, I can read MANIFEST. I wouldn't waste my time reading
Makefile*.

[snip]

>
>> CPAN.pm is perhaps too much of a power user's tool, since there's no
>> easy way to restore what you had, but I can't think offhand of any
>> MacOS installer that lets you go back easily.
>
>Any drag-n-drop installer can be undone, but they don't really count for
>our purposes.

When was the last time you saw a drag-and-drop installer? cpan-mac got us
*away* from drag-and-drop installation of Perl modules, and I for one
think that is a vast improvement. Before Chris made the port, I was
opposed to putting MacPerl patched modules in CPAN, becaues it's a pain in
the neck to install a .tar.gz on a Mac. I didn't have a PAUSE id then. I
had my own installer written in Perl to do the job for the modules I had
ported, which I distributed on my own. That installer *did* save the
previous version for easy reversion (simply run the installer again and
the old version was installed). I happily abandoned that when CPAN.pm
became usable under MacPerl.

I was thinking of the standard installers that are used for most MacOS
software. Usually there is an "uninstall", but that by no means means
"revert to previous state". If you uninstall, you no longer have the
software at all.

[snip]
>
>Wouldn't it be less work to patch up the install regarding binaries, for
>cases like HTML::Parser?  As far as the README on ported modules goes,
>anything would be good.  But I'm also now resigned to see nothing done,
>because hopefully ports will soon disappear and hopefully the effort will
>be better spent elsewhere.
>

As they say, patches welcome.

But I really think that the class of people for which this is an actual
problem is pretty small. Completely clueless people don't use Perl. People
who do use Perl usually can follow instructions and learn. IF there's any
problem here, it's a problem of documentation at most, and I don't even
think that's true. Chris has the appropriate warnings in the README in
cpan-mac. I admit to frequently not reading README's, but if the
information is available, then I've no reason to complain if something
goes wrong.
 
>
>
>--
>MattLangford 
>
>
>
>
>

-------
Paul J. Schinder
schinder@pobox.com


==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-porters-request@macperl.org