Re: [MacPerl-Porters] Identifying Ported Modules

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

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.

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.

> If you, say, install HTML::Parser, which has now gone pure XS, from
> CPAN, all you need to do is pull Parser.pm out of your site_perl and
> you're back to normal.

Unix, without the ability to compile the XS portion, would not have even
placed Parser.pm in the first place.  This is the correct behavior.

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.

> Linux and Solaris users are
> better protected in some ways simply because a lot of them *can't* affect
> the core Perl distribution, since they don't have th necessary
> permissions. But if you do have the permissions, you can easily break
> things.

Many actions that would break something under Linux or Solaris will also
break things under MacOS.  Even if Linux and Solaris win by volume of
platform-unique, non-intuitive, confusing, and installation-breaking CPAN
behaviors, what does that mean?  Should CPAN.pm under MacPerl become more
confusing?  Should it not be made better, for fear of widening a platform
ease-of-use gap?  If, on the other hand, MacPerl has more
you-shoulda-knowns, can we not fix problems as we find them?


> 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.

CPAN.pm has all the information it needs to un-install:  it knows exactly
what will go where, and it can find out what is pre-existing.  All it
needs is to save this list of copied files, a list of files which were
saved because they were being replaced, and the saved files themselves.
All these can be bundled up and compressed, and saved in an uninstall
cache folder.  CPAN.pm could treat this like the sources/build caches, and
ask when it gets ready to wipe out an older uninstall.  

Oh, yes, and one other thing is necessary:  a master cache list detailing
which installs touched which files (only as far back as the oldest cache
member).  If you ask to uninstall a package, one of whose files was
replaced by more recent installs, CPAN.pm could ask if you wanted to
uninstall them first.

What about platforms without shared libs?  Two choices:  one, disable the
uninstall capability.  Two, save as many of the massive builds in the
cache directory as can fit in the uninstall cache size.  Probably not
many.

It's easy on e-paper.  :)


> We probably need a README that says "these are ported, be careful what
> you do to them". I perhaps should have sent a message to the mailing
> list saying "watch out, HTML::Parser is now pure XS, stay away from
> the 3.x series or wait for it to show up on mmp". Since I'm aware of
> such things from cpan-testers, I could start doing that.

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.




--
MattLangford 




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