On January 26, 2005 12:00 pm, Steve Simms wrote:
> On Wed, 26 Jan 2005, Christopher Browne wrote:
> > Darcy Buskermolen wrote:
> >> On January 25, 2005 11:02 pm, Steve Simms wrote:
> >>> - "make install".  There doesn't seem to be any included way of
> >>>   installing these tools.  On my machine, I'm still running them from
> >>>   /usr/local/src/slony-1.0.5/tools/altperl.
> >>>
> >>>   I'd like to see the administration tools be installed when "make
> >>>   install" is run, in the same directory as slon and slonik. 
> >>> Preferably when Slony's "make install" is run, but I'll take a separate
> >>> "make altperl-install" if that's too much to ask.
> >>
> >> This is not a big deal, but I'd be inclined not to have them installed
> >> via the standard make install target since I won;t nessarly have perl
> >> installed on any box but my admin station.
>
> Could it be set up such that if Perl is present, they're installed with a
> "make install", and not otherwise?  (Or, if a --with-perl option, or
> something to that effect.)

changes have been commited to -HEAD to have a make all target which does 
hashbang substitution and removes the .pl file extention (a ./configure is 
required)

As it stands now, if perl dosn't exist on the system the make all in 
tools/altperl will fail with a error message.

>
> > If they are put in some subdirectory, e.g. $PGHOME/share/slony1/scripts,
> > that seems reasonable to me.
>
> For the executable files, I'd like to have them in the path somewhere by
> default, or have a configuration switch that will let me put them there.
> I'm much less concerned about the library location, as long as the scripts
> know where to look.

Once we have decided on a path i can add a make install target.

>
> >>> - Configuration file revamp.  Currently, the configuration file is a
> >>> Perl script itself, and is assumed to be in the current working
> >>> directory, though it would also work if it were anywhere in Perl's list
> >>> of library paths.  The --config option I've been adding makes it
> >>> possible to specify a different configuration file from the
> >>> command-line, but that is a pain to include with each command.
> >>>
> >>>   Instead, I'd like to have a configuration file akin to the
> >>> postgresql.conf file, perhaps in the same directory, or some /etc
> >>> location.
> >>> This would allow other tools (including non-Perl tools) to use the same
> >>> configuration file down the road.
> >
> > It would be sort of neat to have a quasi-standard way of describing
> > cluster configuration.  But I wouldn't want to add complexity for this
> > particularly when we don't yet have a "second tool" that knows how to
> > read it. - I'd hate to create an XML format that's liable to be
> > half-baked; - I'd hate to create some scheme that would encourage needing
> > to integrate in a Yacc parser;
> > - My "marginal" preference would be to use S-expressions, but that would
> > need still another parser for Perl-based usage
>
> Hmm, XML isn't what I had in mind.  More of a "field = value" format,
> possibly divided into sections somehow.
>
> Ideally, I'd like to only have information that can't be pulled in the
> database in this file, which would make it simpler to store.  I don't need
> the entire cluster configuration if I can get that from the database; just
> enough to run commands.
>
> That conflicts with the requirement that these scripts not use DBD::Pg,
> however, unless we get creative with psql or have some other way of
> connecting to the database (libpq?).
>
> So, it might be best to drop that for now, and stick with the Perl
> configuration file, but in a known location set at "make" time.
>
> > What I would _oppose_ for these scripts is the notion of trying to make
> > the scripts too terribly much smarter, e.g. - by integrating in DBI or Pg
> > modules so that they query database state.  Part of the design of these
> > scripts involves them NOT having tight integration with the databases;
> > they are consciously loosely coupled so that they can "play well" in
> > environments where you get Perl provided but where you _can't_ add extra
> > CPAN modules.  In particular, I am thinking of the UNIX(tm) systems: AIX,
> > Solaris, HP/UX, and such.  We're running AIX and Solaris in hosted
> > environments where we don't get to install extensions, and Pg/DBI would
> > be examples of extensions.
>
> On Wed, 26 Jan 2005, Josh Berkus replied:
> > Interesting.  I was about to suggest building altperl as a CPAN module,
> > in fact.  Now I can see how that might not be desirable.
>
> I was also thinking about using CPAN.  If the tools are going to be
> developed in tandem with Slony releases, then it isn't really needed.  If
> we're going to separate their releases, CPAN would be a nice distribution
> method.  It wouldn't preclude downloading the tar.gz and installing it
> locally on a system where CPAN wasn't allowed.
>
> I'd like to go with an "install it if you can" mindset rather than only
> including the lowest common denominator, so that scripts that use more
> advanced features are still available for what I would guess is the
> majority of people who have DBD::Pg available, but there's certainly enough
> to do without getting into that for the time being.
>
> > I can see the desire, eventually, for 2 sets of tools: 1 in altperl which
> > is loosely coupled with no dependancies other than slony, and one as a
> > CPAN module that makes use of DBI, Introspector, ps and other modules.
>
> I would imagine that the "no dependencies" version would eventually be
> rewritten into shell scripts or C.  If I were comfortable with either, I'd
> volunteer to do that.
>
> I wouldn't want the CPAN version to require much more than DBD::Pg if it
> can be avoided -- I don't like installing modules that require 15 other
> modules, half of which haven't seen a 1.0 release.  :-)
>
> >>> - Combine some of the scripts by logical function?  slon_start and
> >>> slon_kill could be combined into slon_ctl, for example.
> >>
> >> Yes I think this is a good idea and fits with the standard of how pg
> >> does it.
> >
> > Sure, that seems reasonable.  In CVS HEAD, you get to specify where the
> > PID gets stored when a slon is started, so it would make a lot of sense
> > for there to be a slon_ctl that specifically looks for this.
> >
> > I'd tend to think slon_ctl should be implemented as a shell script as
> > opposed to Perl to be consistent with "tradition"...
>
> I could probably manage this by looking at other implementations.  Perl is
> easiest for me, as I've been writing in it every day for some three years
> now, so it's what I go with barring any reason to use another tool.
>
> Thanks,
> Steve Simms
>
> --
> Steve Simms <steve at deefs.net>
> http://www.deefs.net
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general

-- 
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com