RT and the Perl Dependency Nightmare

Greetings all,

Is there any official list that indicates the correct order for
building and installing the multitude of Perl modules from CPAN?
I’m running into some strange circular dependencies.

Also, e.g. since there’s this problem with pod2test disappearing and
making the WWW::Mechanize (or was it Test::WWW::Mechanize?!?) module
die upon building, do the RT folks have a repository of all the Perl
module sources required for a successful end product that are
publicly available to pair up with the RT release (specifically
3.4.4) that we can simply grab and rebuild?

And while I’ve got your attention, how does everyone else handle the
fact that there are ~100 perl modules from CPAN required for RT that
are randomly (almost chaotically) changing individually and in
almost certainly incompatible ways?

I’m just trying to get a handle on it, that’s all.

Thanks!
-Tim

Timothy E. Miller, PhD, RHCE voice: (336)758-3257
Systems Analyst Lead, High Performance Computing fax: (336)758-7127
Wake Forest University cell: (336)782-6987
Computer Science, Information Systems, Physics

Timothy E Miller wrote:

Is there any official list that indicates the correct order for
building and installing the multitude of Perl modules from CPAN?
I’m running into some strange circular dependencies.

Do a search on the mailing lists here for “Perl dependecies problem”.
There were some issues with WWW::Mechanize, it along with some other
modules need to be forced. You should find what you need with this
search. Also, 3.4.4 has fixed a few of those issues. Good luck.

Max

Is there any official list that indicates the correct order for
building and installing the multitude of Perl modules from CPAN?
I’m running into some strange circular dependencies.

I recently made everything work on an up to date Centos4 box
by installing Pod::Tests first with CPAN (for the apparently
moved pod2test), then a force install of WWW:Mechanize and
Test::More. Then running the RT script should pick up
everything else.

Also, e.g. since there’s this problem with pod2test disappearing and
making the WWW::Mechanize (or was it Test::WWW::Mechanize?!?) module
die upon building, do the RT folks have a repository of all the Perl
module sources required for a successful end product that are
publicly available to pair up with the RT release (specifically
3.4.4) that we can simply grab and rebuild?

I think the WWW::Mechanize problem happens regardless of the
source version. It looks like it is testing content from
an internet location that has changed or is no longer
available.

And while I’ve got your attention, how does everyone else handle the
fact that there are ~100 perl modules from CPAN required for RT that
are randomly (almost chaotically) changing individually and in
almost certainly incompatible ways?

I’m just trying to get a handle on it, that’s all.

It would be nice if those were all bundled into our favorite
OS distributions. However, if someone else packages them
in a way that the system package manger understands there
will be new conflicts if they are later included in the
distribution. I’m not sure there is an answer better than
wading through the CPAN install problems as they happen.

Les Mikesell
les@futuresource.com

And while I’ve got your attention, how does everyone else handle the
fact that there are ~100 perl modules from CPAN required for RT that
are randomly (almost chaotically) changing individually and in
almost certainly incompatible ways?

I’m just trying to get a handle on it, that’s all.

It would be nice if those were all bundled into our favorite
OS distributions. However, if someone else packages them
in a way that the system package manger understands there
will be new conflicts if they are later included in the
distribution. I’m not sure there is an answer better than
wading through the CPAN install problems as they happen.

Well, I guess my email was more about how people (or event the RT
developers) handle “this”, where “this” is installing an identical,
complete and (presumably) working RT service on different systems at
different times. In an RPM world, you simply build (ugh) all the
Perl modules into RPMs and incorporate them into a kickstart
process. Viola! You can clone (DB issues aside) a billion RT
servers a year from now and know you have an identical setup.

So, did they (RT devs), at one point in time, find the perfect mix
of modules, install them via CPAN and then build a CD iso of that
system in order to repeated clone that “perfect” set of modules?
Do the roll the dice with versions in CPAN everytime they install
RT?

My goal, if it isn’t clear from above, is that I want to be able to
find some method of automatically provisioning a system to be an RT
server at any point in time and not worry about a new version of
Apache::Session or HTML::Forms or Digest::MD5 blowing the whole
thing up. Primarily this is a disaster recovery goal (the DB is on
a DB server that, already, has DR capability). My imaging setup is
RPM based so this becomes a challenge but only because of the CPAN
installation part (most of which is mitigated by cpan2rpm … but
only if you can build the 100 or so freakin’ RPMs).

Comments and thoughts are greatly appreciated.
-Tim

Timothy E. Miller, PhD, RHCE voice: (336)758-3257
Systems Analyst Lead, High Performance Computing fax: (336)758-7127
Wake Forest University cell: (336)782-6987
Computer Science, Information Systems, Physics

Well, I guess my email was more about how people (or event the RT
developers) handle “this”, where “this” is installing an identical,
complete and (presumably) working RT service on different systems at
different times. In an RPM world, you simply build (ugh) all the
Perl modules into RPMs and incorporate them into a kickstart
process.

OK, but what do you expect to happen when your RPM based
distribution includes a conflicting updated RPM and
you want to do an update? Or you’ve updated, then want
to install your bundle?

Viola! You can clone (DB issues aside) a billion RT
servers a year from now and know you have an identical setup.

But a year from now you’ll want the updated versions not
a frozen set that probably have a lot of bugs we just
haven’t found yet.

My imaging setup is
RPM based so this becomes a challenge but only because of the CPAN
installation part (most of which is mitigated by cpan2rpm … but
only if you can build the 100 or so freakin’ RPMs).

I think you have the right idea, but either the RPMs have to
get pushed into the main OS distribution at the start of
the project or they need to install as an RT library
in a place that is searched first and doesn’t conflict
with anything the OS may or may not include. If you
just want the ability to put back exactly what you had,
any number of tar/dump/rsync based backup programs can
do that. (I happen to like http://backuppc.sourceforge.net/).
However the real value of RPM packaging is that with
yum/up2date/apt-get/urpmi, etc., any number of systems
can stay current with updates made to a central
repository. If you aren’t planning for the update capability
it doesn’t seem worth the extra effort to do rpm packaging
compared to a script that installs the CPAN tarballs and
saving a copy of the versions you want.

Les Mikesell
les@futuresource.com

Hi Tim,

Running on RedHat myself, I’ve given up on trying to run RT with RedHat’s
perl. I’ve compiled and installed my own perl into /usr/local and I use
CPAN to install all the required modules. I used to use cpan2rpm but as
perl and required modules got newer while my system’s perl got older, things
started breaking.
In any case, perhaps having your own package(s) which include your own perl
and modules would make sense. Instead of using the 'net to download and
install the latest version of Package::Foo, store the tarball somewhere
and/or make an RPM out of it. This would all certainly take some time to
do. If you chose to store the tarball and do a “/usr/local/bin/perl
Makefile.pl && make && make install” you’ll want to make sure it’s all done
in the right order and that doing it in a kickstart environment won’t fail -
not necessarily easy. For reference, here’s my PERL and RT build/install
process from when I installed perl 586 and RT 323. There’s some references
to modules I needed when I upgraded as well. Note that this is via the CPAN
"install" command which isn’t what I’m suggesting you use but it may help
you get an idea of module list/order. Watch line wraps.

sh

Edit these as appropriate

export PERL=5.8.6

rm -rf perl-$PERL

tar -xzf …/distfiles/perl-$PERL.tar.gz
cd perl-$PERL

sh Configure -des -Doptimize="-O2 -march=i386 -mcpu=i686" -Dcc=gcc
-Dcccdlflags=-fPIC -Darchname=i386-linux -Uusethreads -Uuseithreads
-Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm
-Di_shadow -Di_syslog -Dman3ext=3pm
make
make install

/usr/local/bin/perl -MCPAN -e shell

set up CPAN if necessary

The following are all for RT 3.2.3 dependencies

install LWP::UserAgent (default answers)
install Params::Validate
install Cache::Cache (default answers)
install Exception::Class (default answers)
install HTML::Mason (default answers, but skip test suite for Apache::Test)
install MLDBM
install FreezeThaw
install DBI
o conf makepl_arg "–testpassword=test --testuser=test"
install DBD::mysql
o conf makepl_arg ""
install DB_File
install Apache::Session
install XML::Parser
install XML::RSS (default answers)
install HTML::TreeBuilder
install HTML::FormatText (default ansers)
install Getopt::Long
install Test::Inline
install Class::ReturnValue
install DBIx::SearchBuilder (default answers)
install Text::Template
install HTML::Scrubber
install Module::Build
install Log::Dispatch
install Locale::Maketext::Lexicon
install Locale::Maketext::Fuzzy
install MIME::Entity (default answers)
install Text::Wrapper
install Time::ParseDate
install Term::ReadKey
install Text::Autoformat (default answers)
install Text::Quoted
install Tree::Simple (default answers)
install Module::Versions::Report
install Regexp::Common
install WWW::Mechanize
install Crypt::SSLeay
force install Apache::DBI

The following was done to upgrade from RT 3.2.3 to RT 3.4.2

SB needed an upgrade:

install DBIx::SearchBuilder
install HTTP::Server::Simple
install Hook::LexWrap
install HTTP::Server::Simple::Mason
install XML::Simple
install Test::LongString
install Test::WWW::Mechanize
install Module::Refresh

RTFM

install Text::WikiFormat

RT 3.5.x

install GD
install GD::Text
install GD::Graph
install Calendar::Simple

FastCGI

install FCGI

RT

cd rt-3.4.2
PERL=/usr/local/bin/perl ./configure --prefix=/usr/local/rt3
–with-web-user=nobody --with-web-group=nobody
–with-apachectl=/usr/local/apache/bin/apachectl
make upgrade

Running on RedHat myself, I’ve given up on trying to run RT with RedHat’s
perl. I’ve compiled and installed my own perl into /usr/local and I use
CPAN to install all the required modules. I used to use cpan2rpm but as
perl and required modules got newer while my system’s perl got older, things
started breaking.

RedHat what? RHEL4.x should work, along with Fedora FC2 and up and the
free Centos4 rebuild of RHEL4.

You might have the right idea in building a local copy of everything
so you can keep it intact regardless of the OS distribution or
updates though.

Les Mikesell
les@futuresource.com

It’s RH 7.3 :slight_smile:
It probably does work with recent versions but RH 7.3 was recent at one
point, too. Keeping it independent of the OS means I don’t have to worry
about the conflicts that will eventually arise as RT, Perl, and all the Perl
modules continue to evolve. It also means that upgrading to RHEL3/4 will be
a lot easier since I don’t have to worry about what will happen to the
vendor Perl installation.

-=| Ben

Hi Tim,

Running on RedHat myself, I’ve given up on trying to run RT with RedHat’s
perl. I’ve compiled and installed my own perl into /usr/local and I use
CPAN to install all the required modules. I used to use cpan2rpm but as
perl and required modules got newer while my system’s perl got older, things
started breaking.
I agree here about RH’s perl. I didn’t see normal builds in RH 9, 9.2,
FC1.(I don’t use RH based distros any more)

[snip]

sh

Edit these as appropriate

export PERL=5.8.6

rm -rf perl-$PERL

tar -xzf …/distfiles/perl-$PERL.tar.gz
cd perl-$PERL

sh Configure -des -Doptimize="-O2 -march=i386 -mcpu=i686" -Dcc=gcc
-Dcccdlflags=-fPIC -Darchname=i386-linux -Uusethreads -Uuseithreads
-Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm
-Di_shadow -Di_syslog -Dman3ext=3pm

I usually took configure options from RH’s perl -V output(perl
sources was vanilla) to be more compatible with RH other environment.

make
make install

/usr/local/bin/perl -MCPAN -e shell

set up CPAN if necessary

[snip]

Best regards, Ruslan.

Running on RedHat myself, I’ve given up on trying to run RT with RedHat’s
perl. I’ve compiled and installed my own perl into /usr/local and I use
CPAN to install all the required modules. I used to use cpan2rpm but as
perl and required modules got newer while my system’s perl got older, things
started breaking.

RedHat what? RHEL4.x should work, along with Fedora FC2 and up and the
free Centos4 rebuild of RHEL4.
IMHO main problems with RH distros are:

  1. RT is not part of distribution, so AFAIU you can’t get support from
    RH(may be I’m wrong).
  2. RH freeze package versions and then only applies patches
    selectively. For eg in RH9 was 5.8.0 available only with a lot of
    patches, when at the same time perl5.8.3(or may be 4) was available at
    perl.org. I even couldn’t compile that RH’s perl from SRPM or it was
    failing on the tests.

You might have the right idea in building a local copy of everything
so you can keep it intact regardless of the OS distribution or
updates though.


Les Mikesell
les@futuresource.com


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Buy your copy of our new book, RT Essentials, today!

Download a free sample chapter from http://rtbook.bestpractical.com

Best regards, Ruslan.

RedHat what? RHEL4.x should work, along with Fedora FC2 and up and the
free Centos4 rebuild of RHEL4.

IMHO main problems with RH distros are:

  1. RT is not part of distribution, so AFAIU you can’t get support from
    RH(may be I’m wrong).

Does some distribution include/support the current RT version?

  1. RH freeze package versions and then only applies patches
    selectively. For eg in RH9 was 5.8.0 available only with a lot of
    patches, when at the same time perl5.8.3(or may be 4) was available at
    perl.org. I even couldn’t compile that RH’s perl from SRPM or it was
    failing on the tests.

Usually that’s a good thing, assuming the starting version is good
enough. After RH9, the distribution split into the fast-cycle
Fedora which you use if you want frequent app-version updates
and RHEL (and the free rebuilds like Centos followed) where the
updates are bugfix backports which you use if you don’t want
frequent behavior-changing updates.

FC2 included perl-5.8.3 which was OK for RT3. FC4 is at 5.8.6.
RHEL4 (and thus Centos4) have perl-5.8.5, probably with some
bugs fixed by backporting later changes. None of those should
have perl-related issues regarding RT other than how to install
and maintain the many needed extra modules that aren’t included
in the distribution.

Les Mikesell
les@futuresource.com

RedHat what? RHEL4.x should work, along with Fedora FC2 and up and the
free Centos4 rebuild of RHEL4.

IMHO main problems with RH distros are:

  1. RT is not part of distribution, so AFAIU you can’t get support from
    RH(may be I’m wrong).

Does some distribution include/support the current RT version?

  1. RH freeze package versions and then only applies patches
    selectively. For eg in RH9 was 5.8.0 available only with a lot of
    patches, when at the same time perl5.8.3(or may be 4) was available at
    perl.org. I even couldn’t compile that RH’s perl from SRPM or it was
    failing on the tests.

Usually that’s a good thing, assuming the starting version is good
enough. After RH9, the distribution split into the fast-cycle
Fedora which you use if you want frequent app-version updates
Exactly this change in FC makes it more attractive for RT.

and RHEL (and the free rebuilds like Centos followed) where the
updates are bugfix backports which you use if you don’t want
frequent behavior-changing updates.
IMHO backports are root of the problems. Changes between 5.8.5 and
5.8.7 is not 5 patches, but 1000(may be less or may be more). And if
someone in RH backports 1-100 patches it doesn’t mean he only fixes
bugs, but he also may unhide “new” bugs. You can’t just take 1, 13 and
199 patches and apply it to previouse version because patch 13 makes
bug XXX bite you more often then it was before(this bug was fixed in
patch 7). And in this case RH’s perl maintainer couldn’t fix it, he is
not perl hacker(or may be he is, I don’t know). Perl p5p doesn’t care
about such bugs, if there is new version available where bug is not
introducible then it’s your problem how to fix it.

FC2 included perl-5.8.3 which was OK for RT3. FC4 is at 5.8.6.
RHEL4 (and thus Centos4) have perl-5.8.5, probably with some
bugs fixed by backporting later changes. None of those should
have perl-related issues regarding RT other than how to install
and maintain the many needed extra modules that aren’t included
in the distribution.


Les Mikesell
les@futuresource.com

Best regards, Ruslan.

Now, you all just complain, but you can take Paulo’s RPMs and update
specs to new versions and publish it, can’t you? Yes, you can. Change
the situation.
There is ebuild for Gentoo. There is deb packages. Look into it, I
think it’s good examples, you can learn from it.

Ask your bosses to fund such activity, it would be good feedback for
using RT free.

It’s open source, but you have alternative way sales@bestpractical.comOn 9/9/05, Ruslan Zakirov ruslan.zakirov@gmail.com wrote:

On 9/9/05, Les Mikesell les@futuresource.com wrote:

On Thu, 2005-09-08 at 16:08, Ruslan Zakirov wrote:

RedHat what? RHEL4.x should work, along with Fedora FC2 and up and the
free Centos4 rebuild of RHEL4.

IMHO main problems with RH distros are:

  1. RT is not part of distribution, so AFAIU you can’t get support from
    RH(may be I’m wrong).

Does some distribution include/support the current RT version?

  1. RH freeze package versions and then only applies patches
    selectively. For eg in RH9 was 5.8.0 available only with a lot of
    patches, when at the same time perl5.8.3(or may be 4) was available at
    perl.org. I even couldn’t compile that RH’s perl from SRPM or it was
    failing on the tests.

Usually that’s a good thing, assuming the starting version is good
enough. After RH9, the distribution split into the fast-cycle
Fedora which you use if you want frequent app-version updates
Exactly this change in FC makes it more attractive for RT.

and RHEL (and the free rebuilds like Centos followed) where the
updates are bugfix backports which you use if you don’t want
frequent behavior-changing updates.
IMHO backports are root of the problems. Changes between 5.8.5 and
5.8.7 is not 5 patches, but 1000(may be less or may be more). And if
someone in RH backports 1-100 patches it doesn’t mean he only fixes
bugs, but he also may unhide “new” bugs. You can’t just take 1, 13 and
199 patches and apply it to previouse version because patch 13 makes
bug XXX bite you more often then it was before(this bug was fixed in
patch 7). And in this case RH’s perl maintainer couldn’t fix it, he is
not perl hacker(or may be he is, I don’t know). Perl p5p doesn’t care
about such bugs, if there is new version available where bug is not
introducible then it’s your problem how to fix it.

FC2 included perl-5.8.3 which was OK for RT3. FC4 is at 5.8.6.
RHEL4 (and thus Centos4) have perl-5.8.5, probably with some
bugs fixed by backporting later changes. None of those should
have perl-related issues regarding RT other than how to install
and maintain the many needed extra modules that aren’t included
in the distribution.


Les Mikesell
les@futuresource.com


Best regards, Ruslan.

Best regards, Ruslan.

My thoughts below aren’t necessarily what I believe; rather, they’re to
invoke additional thought on this discussion.

While the fact that RT relies on modules rather than reinventing the wheel
is a Good Thing, there are benefits and drawbacks. Exploring them again is
probably a good exercise even if it’s been done before - RT and its users
continually change.

For example, in the single distribution scenario, not only would
installation be easier, but general support would be easier as well; instead
of 1000 permutations of versions and bugs, you have 1. Imagine if Firefox
required a large number of modules that are largely maintained by others.
Would it be as successful?

It’s surely an interesting debate that’s almost religious in nature (like
the “which linux distro is better” question) and has obvious pro’s and
con’s. Creating a single package would surely not be easy to do, either.

To Ruslan’s point - maybe someone does need to spend the time to make (and
maintain
) a robust (hopefully somehow multiplatform) package to cater to
the crowd who, for whatever reason, can’t run RT in its current form. Such
a task is not to be underestimated, however. We’d be dealing with different
distributions, operating systems, and architectures. In any case, this
isn’t a small or easy conversation. Right now what it all really comes down
to is each individual’s needs and the best way to satisfy them.

Also remember what Best Practical is from a company standpoint. They don’t
make and sell a commercial product - they create open source software and
draw revenue from things like support, training, and special customizations.
It’s a different model than a lot of people are used to.

-=| Ben

My thoughts below aren’t necessarily what I believe; rather, they’re to
invoke additional thought on this discussion.

While the fact that RT relies on modules rather than reinventing the wheel
is a Good Thing, there are benefits and drawbacks. Exploring them again is
probably a good exercise even if it’s been done before - RT and its users
continually change.

For example, in the single distribution scenario, not only would
installation be easier, but general support would be easier as well; instead
of 1000 permutations of versions and bugs, you have 1. Imagine if Firefox
required a large number of modules that are largely maintained by others.
Would it be as successful?
Please, don’t mix different things. Firefox is client side software.
RT is SERVER side, this means by default that people who install it
should have more knowledge. Let’s stop this conversation here. RT has
much dependencies right now and IMHO nobody could change this.

But you can at least make current installation system better. You
don’t need to know RT internals, but you should know perl a little,
here is tasks you could do:

  • rt-test-dependencies script
    ** require more user friendly reports
    *** should hide building process, and only report that module
    successfuly installed
    *** should report errors to file with additional info about users perl
    and instructions how to use this file
    ** could do smart things:
    *** rt-test-dependencies script uses CPAN.pm, AFAIK this module allow
    install not only latest available module, but also particular version
    you want, so script could fallback to previouse versions if latest
    fails to install.
    *** also it’s easy to hack this script to use other software instead
    of CPAN.pm, I even have such patch somewhere, I used it to install RT
    deps via Gentoo’s g-cpan programm(something like cpan2rpm for gentoo).

Fix this and installation process would be more painless

It’s surely an interesting debate that’s almost religious in nature (like
the “which linux distro is better” question) and has obvious pro’s and
con’s. Creating a single package would surely not be easy to do, either.

To Ruslan’s point - maybe someone does need to spend the time to make (and
maintain
) a robust (hopefully somehow multiplatform) package to cater to
the crowd who, for whatever reason, can’t run RT in its current form. Such
a task is not to be underestimated, however. We’d be dealing with different
distributions, operating systems, and architectures. In any case, this
isn’t a small or easy conversation. Right now what it all really comes down
to is each individual’s needs and the best way to satisfy them.
Prefer change “the best” to “the fastest”.

Also remember what Best Practical is from a company standpoint. They don’t
make and sell a commercial product - they create open source software and
draw revenue from things like support, training, and special customizations.
It’s a different model than a lot of people are used to.

    -=| Ben

-----Original Message-----
From: Ruslan Zakirov [mailto:ruslan.zakirov@gmail.com]
Sent: Thursday, September 08, 2005 6:55 PM
To: Les Mikesell
Cc: Ben Goodwin; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT and the Perl Dependency Nightmare…

Now, you all just complain, but you can take Paulo’s RPMs and update
specs to new versions and publish it, can’t you? Yes, you can. Change
the situation.
There is ebuild for Gentoo. There is deb packages. Look into it, I
think it’s good examples, you can learn from it.

Ask your bosses to fund such activity, it would be good feedback for
using RT free.

It’s open source, but you have alternative way sales@bestpractical.com

Best regards, Ruslan.

All right, since everyone is blowing this way out of proportion, I
guess I should respond … in like outrageous fashion.

[RT-Perl modules below refers to Perl modules from CPAN req’d by RT]

Les, “what do I do when Red Hat upgrades Perl?” Answer NOTHING!
That’s the whole point of the Enterprise product line, security and
bug fixes ONLY. NO NEW FEATURES. In principle (and sure it’s a bit
naive), nothing breaks except the “bugs” (i.e. the bugs don’t work
any more so they’re “broken”…get it? Ha, ha! :slight_smile:

As I’m a realist, some RT-Perl modules might not work OR more
realistically, some of the RT-Perl modules/RPMS overwrote what Red
Hat shipped. Answer again is simple, reinstall my RT Perl RPMS on
top of it.

The whole point is NOT some beautiful, static, utopian situation.
The point is MAINTAINABILITY and REPRODUCIBILITY. If I upgrade Perl
and something breaks, Hmmm… maybe it was the Perl upgrade. If I
decide to upgrade the DBIx::SearchBuilder module and something
breaks, then maybe it was the upgrade.

If I take and provision a second webserver to deploy RT on (so I can
shutdown the primary and do maintenance on it), it’d be nice to know
I’ll have a working RT on it. Other’s prior knee jerk “just rsync
it” or “restore from backup” completely missed my statement of being
RPM based (especially in the imaging side).

With the current RT installation method, so much **** changes in
Perl CPAN land from version to version that I have to spend a whole
week trying to debug when to ignore this failed test or which
packages I have to force. And since I don’t do regular (read:
religious) upgrades of RT from minor-sub-release to minor-sub-release,
I then have to jump from 3.2.x to 3.4.4 with a whole new slew of
package dependencies. Remember, I’m a sysadmin… not an RT admin.

I can not (and will not) believe the RT developers at Best Practical
operate that way. Trusting that 20+ independent Perl developers
make only perfect bug-fixing upgrades (synchronized, no less) that
still all magically interoperate as they previously did without
breaking is only for children who believe in Santa Claus and people
who think the govt is here to help you.

There is no way someone who does this for a living does not have a
set of Perl modules squirreled away for which they test incremental
development. Maybe RT devs don’t. Maybe every now and then (say
for major releases), they just fire off a big “CPAN upgrade all my
modules to the latest version” command and then fix what is broken.
As an admin/developer, I don’t think so.

And maybe the answer is to take a build a completely separate Perl,
Apache, mod_perl, RT, and RT-Perl (RT req’d perl modules) directory
tree and just tar it up and RPM-ize it. I don’t know.

I was just soliciting folks for more production ready methods that
they may have used or developed rather than the current old school
manual hack currently in place.

-Tim

P.S. Of course, if I had $2k, I imagine the first thing I’d get from
BestPractical is a CD with all the Perl modules with the correct
software versioning and dependencies taken care of.On Wed, 7 Sep 2005, Les Mikesell wrote:

OK, but what do you expect to happen when your RPM based
distribution includes a conflicting updated RPM and
you want to do an update? Or you’ve updated, then want
to install your bundle?

Viola! You can clone (DB issues aside) a billion RT
servers a year from now and know you have an identical setup.

But a year from now you’ll want the updated versions not
a frozen set that probably have a lot of bugs we just
haven’t found yet.

My imaging setup is
RPM based so this becomes a challenge but only because of the CPAN
installation part (most of which is mitigated by cpan2rpm … but
only if you can build the 100 or so freakin’ RPMs).

I think you have the right idea, but either the RPMs have to
get pushed into the main OS distribution at the start of
the project or they need to install as an RT library
in a place that is searched first and doesn’t conflict
with anything the OS may or may not include. If you
just want the ability to put back exactly what you had,
any number of tar/dump/rsync based backup programs can
do that. (I happen to like http://backuppc.sourceforge.net/).
However the real value of RPM packaging is that with
yum/up2date/apt-get/urpmi, etc., any number of systems
can stay current with updates made to a central
repository. If you aren’t planning for the update capability
it doesn’t seem worth the extra effort to do rpm packaging
compared to a script that installs the CPAN tarballs and
saving a copy of the versions you want.

Timothy E. Miller, PhD, RHCE voice: (336)758-3257
Systems Analyst Lead, High Performance Computing fax: (336)758-7127
Wake Forest University cell: (336)782-6987
Computer Science, Information Systems, Physics

[snip]

With the current RT installation method, so much **** changes in
Perl CPAN land from version to version that I have to spend a whole
week trying to debug when to ignore this failed test or which
packages I have to force. And since I don’t do regular (read:
religious) upgrades of RT from minor-sub-release to minor-sub-release,
I then have to jump from 3.2.x to 3.4.4 with a whole new slew of
package dependencies. Remember, I’m a sysadmin… not an RT admin.

I can not (and will not) believe the RT developers at Best Practical
operate that way. Trusting that 20+ independent Perl developers
make only perfect bug-fixing upgrades (synchronized, no less) that
still all magically interoperate as they previously did without
breaking is only for children who believe in Santa Claus and people
who think the govt is here to help you.

Yes, they do operate that way. They can do that becuase RT has
regression tests. Each of the perl Modules RT uses has regression
tests. Sometimes there is a bug with a particular version of a
perl module that is not caught until someone reports it, but
mostly things just work fine and it is largely the result of
regression testing. Regression testing = Sant Claus!

[snip]

-Todd

I can not (and will not) believe the RT developers at Best Practical
operate that way. Trusting that 20+ independent Perl developers
make only perfect bug-fixing upgrades (synchronized, no less) that
still all magically interoperate as they previously did without
breaking is only for children who believe in Santa Claus and people
who think the govt is here to help you.

Some people believe that published interfaces are not supposed
to change. It does take a certain amount of faith to maintain that
belief…

There is no way someone who does this for a living does not have a
set of Perl modules squirreled away for which they test incremental
development. Maybe RT devs don’t.

Well, yes, everyone who has built a working RT has a copy of
the working modules squirreled away in their .cpan/sources
and .cpan/build caches whether they know it or not. And
yes, I’ve resorted to grabbing copies of them for another
machine now and then.

Maybe every now and then (say
for major releases), they just fire off a big “CPAN upgrade all my
modules to the latest version” command and then fix what is broken.
As an admin/developer, I don’t think so.

Realistically, I’d guess that most people build a new copy
on a different machine with the latest of everything instead
of lots of in-place updates - then move the database when
the new version works.

And maybe the answer is to take a build a completely separate Perl,
Apache, mod_perl, RT, and RT-Perl (RT req’d perl modules) directory
tree and just tar it up and RPM-ize it. I don’t know.

I did miss the point of the RPM-ize step. Is it really a win
to do this compared to a scripted install of the corresponding
(saved) CPAN tarballs or are you doing it to fit into a scheme you
are already using extensively for other parts of your system. It
just seems like more work to get exactly the same thing done
that a ‘perl Makefile.PL; make install’ would do anyway.

Les Mikesell
les@futuresource.com

After RH9, the distribution split into the fast-cycle

Fedora which you use if you want frequent app-version updates
Exactly this change in FC makes it more attractive for RT.

Not really. With FC you have to do complete system version
upgrades often, something fairly painful when complicated apps
like RT are present.

and RHEL (and the free rebuilds like Centos followed) where the
updates are bugfix backports which you use if you don’t want
frequent behavior-changing updates.
IMHO backports are root of the problems. Changes between 5.8.5 and
5.8.7 is not 5 patches, but 1000(may be less or may be more). And if
someone in RH backports 1-100 patches it doesn’t mean he only fixes
bugs, but he also may unhide “new” bugs.

It’s not perfect of course, but often the tradeoff works in your
favor compared to the number of new bugs introduced in the
untested code of the latest version. You just have to get
past the versions that really screwed up the international
character set handling.

Les Mikesell
les@futuresource.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My two cents (if its worth that much). When I installed RT I isolated it to
have its own version of perl so that everything was contained in /opt/rt. This
makes life easier when you do need to pick up and move to another system.

I am in the process of writing a SPEC file (in my spare time) that will create
an RPM of rt and rt-perl. This will allow me to do an installation via RPM to
any system, easily. I may further create an RPM for RTIR and RTFM in the future
as I am using both. I’ll post the SPEC on the WIKI once I have a good working copy.

Les Mikesell wrote:> On Thu, 2005-09-08 at 21:19, Timothy E Miller wrote:

I can not (and will not) believe the RT developers at Best Practical
operate that way. Trusting that 20+ independent Perl developers
make only perfect bug-fixing upgrades (synchronized, no less) that
still all magically interoperate as they previously did without
breaking is only for children who believe in Santa Claus and people
who think the govt is here to help you.

Some people believe that published interfaces are not supposed
to change. It does take a certain amount of faith to maintain that
belief…

There is no way someone who does this for a living does not have a
set of Perl modules squirreled away for which they test incremental
development. Maybe RT devs don’t.

Well, yes, everyone who has built a working RT has a copy of
the working modules squirreled away in their .cpan/sources
and .cpan/build caches whether they know it or not. And
yes, I’ve resorted to grabbing copies of them for another
machine now and then.

Maybe every now and then (say
for major releases), they just fire off a big “CPAN upgrade all my
modules to the latest version” command and then fix what is broken.
As an admin/developer, I don’t think so.

Realistically, I’d guess that most people build a new copy
on a different machine with the latest of everything instead
of lots of in-place updates - then move the database when
the new version works.

And maybe the answer is to take a build a completely separate Perl,
Apache, mod_perl, RT, and RT-Perl (RT req’d perl modules) directory
tree and just tar it up and RPM-ize it. I don’t know.

I did miss the point of the RPM-ize step. Is it really a win
to do this compared to a scripted install of the corresponding
(saved) CPAN tarballs or are you doing it to fit into a scheme you
are already using extensively for other parts of your system. It
just seems like more work to get exactly the same thing done
that a ‘perl Makefile.PL; make install’ would do anyway.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDIYb80I5vtVF88i0RAu+zAKD0n5rRKw5inK/lamNoEnVl6QlOrgCgiYRf
2ojCzwesXcwof2azq1OBoNE=
=m9Ii
-----END PGP SIGNATURE-----