Why SuSE 9.0 vs. 9.1?

[Bill Campbell]

On Fri, Jul 30, 2004, Fairlight wrote:
>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.

Those were examples that worked.  Others didn't.

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

It appears that any perl::Tk clients run from a xterm and ssh fail.

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

Yes.  The same as I've been doing for the last 19 months or so on
a wide variety of Linux, FreeBSD, and SCO OpenServer platforms.

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

It will get better as I expand the documentation with our specific
configuration and usage documentation.  Zope and Plone make some things
quite easy.

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

Prepackaged SRPMS which are built on the target system.  Many of these have
a multitude of build options to tailor them for specific uses (e.g. apache
has almost 60 options for things like mod_perl, mod_ssl, a tonne of php
options, etc.).

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

This is the way it's done.  There are about 30 OpenPKG packages such as
perl-dbi which comprise one or more related modules.  Unlike Caldera's
perl-modules RPMS from OpenLinux, the OpenPKG packages are kept very
current, with security updates coming out immediately as the holes are
found.  Typically the OpenPKG packages are more current than those in the
SuSE releases, and easier to track any security releases.

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

There's an OpenPKG package, perl-openpkg, that is used to make it very easy
to package CPAN products.  I personally use a different method which uses
the PERL_INSTALL_ROOT environment variable to install relative to a package
root (a patch to the ExtUtils::Install module that I submitted several
years ago so I can say that I've contributed to the core perl program :-).

FWIW:  I'm very active on the OpenPKG developer's lists, and have had many
bug fixes and enhancments incorporated in their packages.  The core team of
OpenPKG developers have been extremely responsive.

Bill
--
INTERNET:   bill at Celestial.COM  Bill Campbell; Celestial Software LLC
UUCP:               camco!bill  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

Anyone who cannot cope with mathematics is not fully human.  At best he
is a tolerable subhuman who has learned to wear shoes, bathe and not
make messes in the house.
		-- Lazarus Long, "Time Enough for Love"