CPAN hanging on ExtUtils::MakeMaker even if installed

[Matthew Seaman]

On 22/02/2012 12:48, Jaime Kikpole wrote:
> On Wed, Feb 22, 2012 at 4:26 AM, Matthew Seaman <matthew at freebsd.org> wrote:
>> Speaking as the rt40 port maintainer, I feel you may be making your life
>> unnecessarily difficult here.  The port won't touch your data: it does
>> precisely nothing to the database.  It does let you set default values
>> for DB connection parameters at install time, but that's  not required
>> and you can just use the normal configuration files to the same effect.
> 
> I had no idea.  I assumed that it could only attempt to setup a new
> DB.  Thank you.  That will be a big help.

It's a FreeBSD ports thing -- ports generally do not provide
pre-packaged configurations, on the basis that is what sysadmins are for.

> Does the rt40 port make a new MySQL database by the name of rt4?  My
> current data is in a MySQL database named rt3, which is why I ask.
> How would you recommend getting the migrated data over to the new
> version?

No -- as I said, the port doesn't touch the database at all.  What it
does do is print out a message with some instructions on what to do
next.  Actually, these are pretty much a condensed version of what is in
the README in the rt-4.0.5 sources.

To create a brand-new empty database and associated userid and password
for rt-4.0.5 run:

   /usr/local/sbin/rt-setup-database --action create,acl \
      --prompt-for-dba-password

This will use the defaults specified when you built the port, prompting
you for the password for the privileged DBA login used to do the schema
modification bits. (While you can set that at build time, I don't
recommend it on the basis that it will store the password internally in
plain text.)  You may need to do other dba related bits, like editing
the pg_hba.conf file to allow the new user appropriate access levels.

For upgrades from rt-3.x to rt-4.x, the procedure would be to start with
a copy of your rt3 DB loaded into a new rt4 DB instance -- ie. by using
mysqldump and mysql client to load, or pg_dump and psql to load or the
equivalent for whatever RDBMS you prefer.  Then use rt-setup-database to
apply the required schema updates.

Note: although the rt40 port defaults to using MySQL, personally, I'd
choose PostgreSQL for a new install. (Pg supports full-text indexing
natively, whereas MySQL needs external software and more to do so.)
Switching RDBMSes as part of the upgrade is not a trivial operation, so
unless you have good reason, just stick with whatever DB you've already got.

The DB default of MySQL is what was there historically, and I didn't
think my arbitrarily changing that was justified.

> As a side note, it seems that I've put off the Apache 1.3.x to 2.x
> upgrade for far too long.  The rt40 port requires p5-Log-Dispatch
> which requires some Apache port.  Since apache13 was deprecated in
> November, I'll have to upgrade Apache itself first.  I'm thinking that
> I'll do that today and go with the apache22 port.  I'm open to advise
> on the Apache upgrade if anyone has any.
> 

rt40 can be run with any web server supported by PSGI, which is rather
more than just Apache.  (There's even a built-in pure-perl one, but
that's really not suitable for any sort of serious usage level.)  While
apache22 is the default, p5-Log-Dispatch doesn't have any apache
dependencies that I can see...

How hard the apache upgrade is for you depends on what else you serve
with your apache13 instance currently.  If this is a server dedicated to
RT, then it should be pretty simple.  For a dedicated RT VHOST (or a
dedicated apache instance), and assuming a) you're using mod_perl and b)
you want to use HTTPS, the rt-related config should look something like
this:

<VirtualHost 192.0.2.40:443>
    ServerName rt.example.org

    SSLEngine on
    SSLCertificateFile    www/apache22/certs/rt.example.org-cert.pem
    SSLCertificateKeyFile www/apache22/certs/rt.example.org-key.pem

    AddDefaultCharset UTF-8

    DocumentRoot "/usr/local/share/rt40/html"
    <Location />
        Order Allow,Deny
        Allow from 192.0.2.0/24

        SetHandler modperl
        PerlResponseHandler Plack::Handler::Apache2
        PerlSetVar psgi_app /usr/local/sbin/rt-server
    </Location>
    <Perl>
        use Plack::Handler::Apache2;
        Plack::Handler::Apache2->preload("/usr/local/sbin/rt-server");
    </Perl>
</VirtualHost>

(Just drop the lines starting SSL and change the port number to 80 if
you prefer plain text HTTP.)

There are some more examples in the RT supplied documentation in
/usr/local/share/doc/rt40/web_deployment.pod

>> Hmmm... well, the port doesn't use 'make fixdeps' because it's the ports
>> job to ensure that all the required dependencies are fulfilled.
> 
> That is very good news.  Thank you.
> 
> 
>> However, if I try it manually, everything works just fine.  This is on a
>> system with only the version of E::MM that comes bundled with perl-5.12
>> (which is version 6.56).  The make fixdeps output looks completely
>> different though -- what version of RT are you trying to use?
> 
> RT 4.0.5.  Perl 5.8.9.

I think there may well be moves to drop perl-5.8 support from ports in
the relatively near future.  If you're going to be having an update-fest
anyhow, then I'd recommend switching to perl-5.12 instead.

> Thanks so much for the help.  Its one of the great things about the
> open source community that I'm not at the mercy of a "help desk" that
> say things like "OK, why don't you go ahead and reinstall it, then?"

Thank you.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20120222/3bb11638/signature.pgp