Why SuSE 9.0 vs. 9.1?

[Fairlight]

In the relative spacial/temporal region of
Fri, Jul 30, 2004 at 04:40:10PM -0700, Bill Campbell achieved the spontaneous
generation of the following:
> 
> I can run a perl::Tk client on the SuSE 9.1 system, and have it display
> properly on the X server on my SuSE 9.0 desktop.  I can run the same script
> on the SuSE 9.1 system in a an xterm in a kde session on its own desktop.

Both statements say "can" without a negation.  Which is the failure case,
or is there another?  I'm not trying to be pesky, I'm trying to understand.

So you run the app from the 9.1 system in both cases, just exporting to a
different display.  I follow that.  Which works...or do both and something
else kicks that atom error?

> To make things more interesting, this appears to be related to openssh, and
> running using X11 forwarding.  The ones that work on the SuSE 9.1 desktop
> are in xterms opened via the kde toolbar, but don't run when run under ssh:
> 
> 	xterm -e ssh localhost &
> 
> Running under the same ssh/xterm, other X clients like xeyes work.

Hmmmm.  Didn't you say you even replaced SuSE's openssh with OpenPKG's?

> These problems generally disappear when using the OpenPKG.org packages.
> First off, perl, and most of the perl modules I use are built from SRPMS
> maintained by the OpenPKG team so I only have to deal with a few specific
> packages to apply local modifications (e.g. modifying the OpenPKG version
> of perl to support gdbm and provide shared libraries necessary for
> postgresql).  I spent a good bit of time recently going from the OpenPKG
> Release 2.0 to Release 2.1, and finally got around to documenting the
> changes I make in their distributions here:
> 
> 	http://www.libertysoft.org/openpkg/

Good reference...saving that.

Now as to using OpenPKG, what you said about not building it intimates that
you're using prepackaged distributions of modules like perl/Tk.  That isn't
how I think it should be done.

Basically, I think anything that comes with the perl core (which nowadays
includes CGI, LWP, Digest::MD5, and some other niceties), should stay in as
part of a perl package.  RH was splitting various parts out, which was
just...bad.  You'd want to replace CGI.pm for security reasons but not want
to dink with anything else.  Technically, you could do it, but suddenly you
invalidate the rpm --verify, as I said.

But basically, I just want perl to come with its core in-tact, and then
-always- build sources with -MCPAN to be able to switch to the latest
release of something if I need to.  There are pre-packaged Tk's out there
for ActivePerl for win32, as well, but most of them are the older 800.024
version, which lacks some features, when you really want the 804.027
version (keeping in mind that you want to do a:  use Encode::Unicode; so
that it actually works right, since Tk is now Unicode-friendly...if you
don't, things to to hell -really- fast...major caveat!).  But there are
only a few places that have the 804.027 build compared to the older one.  I
notice that on linux dists as well...a lot are still using the old dist if
they distribute it at all.

Perl's module system was never meant to fall under rpm's purview, IMHO.  It
has its own idea of how things should be done.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html