> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi,
>
> On Mon, 9 May 2005, Christopher Browne wrote:
>
>>> Ok, I have a new patch that seems to fix all our problems:
>>>
>>> http://postgresql.gunduz.org/slony/patches/slony-rpm.patch
>>>
>>> This patch:
>>>
>>> 1. Modifies the spec.in file for rpm builds.
>>> 2. Changes slon_tools.conf to slon_tools.conf-sample in tools/altperl/
>>> .
>>> slon_tools.conf is a non-existent file and breaks RPM dependencies.
>>>
>>> On Red Hat EL ES 4 both make and make rpm worked.
>>>
>>> Could you please review and apply it?
>>
>> I have one issue with it, namely the proposed changes to various Perl
>> scripts thus:
>>
>> replacing...
>> ! $CONFIG_FILE = '@@SYSCONFDIR@@/slon_tools.conf';
>>
>> with...
>> ! $CONFIG_FILE = '@@SYSCONFDIR@@/slon_tools.conf-sample';
>>
>> I don't think we should change all the scripts to automatically refer
>> what is very clearly a sample file.
>>
>> The sample is just that, a sample that should get edited and renamed to
>> slon_tools.conf before scripts try to use it.
>
> If you want make rpm to work, then you need to apply this patch.

What was broken about the proposed patch was that it was going to cause
everyone's configuration, everywhere, to have the altperl tools point to a
sample file that we KNOW is set up with an invalid set of configuration.

The scripts should NOT point to /etc/slon-tools.conf-sample; they should
point to /etc/slon-tools.conf.

> To say the truth, I really don't care whether make rpm is broken or not.
> The RPMs I build and provide will have no such problems.
>
> Hey, there is no slon_tools.conf in the sources and this make our life
> harder.

I don't see why it should.  It is common for applications to have sample
config files, and for the application configuration NOT to point to that
configuration, but rather to wait for the user to set up their legitimate
configuration.

> Look:
>
> [root at buildfarm SPECS]# rpm -ivh
> /usr/src/redhat/RPMS/i686/slony1-1.1.0-beta3.i686.rpm
> error: Failed dependencies:
>          /etc/slon_tools.conf is needed by slony1-1.1.0-beta3.i686
>
> Got it?

Something is broken there.  That file should not be a dependancy for
anything.  It's not needed at install time.  At install time, that file
doesn't exist.

It won't exist until the Gentle User creates it some time later, after
install time.

You are, in effect, forcing the dependancy that the package has to contain
legitimate replication configuration, which is ridiculous to expect at
install time.

That's not even the problem.  The problem was that you were modifying all
of the "altperl" scripts to point to the sample "conf file" which is a
worse than useless default.

The whole point of having the default is so that once the user sets up a
config file, the scripts will automatically point to that as a reasonable
default.

Until they do so, running the scripts will probably lead to them falling
over with some complaint about "/etc/slon-tools.conf" being missing.  This
is the Right Thing; the error message points them to look in the right
directory and see about making sure that the right file is there.  Until
they put it there, the file will be missing, and that's fine.

>> Personally, I don't think that the default filename should be changed.
>> The scripts will indeed break when they discover they haven't a config
>> file.  That strikes me as being consistent with the installation output:
>>
>>  echo "Slony1 has been successfully installed. Before running Slony1,"
>>  echo "be sure to edit /etc/slon.conf-sample and rename it to"
>>  echo "/etc/slon.conf"
>>
>> If you don't "be sure to edit" the file, then everything breaks.
>
> sorry, could not understand it. If you mean that it needs rewording, I'm
> ok with that.

When you build Slony-I from source, it shows the above message.  It tells
you that it has put in a sample, /etc/slon.conf-sample, and that the user
will have to modify that to get /etc/slon.conf

The same is true for someone using RPM, apt-get, or BSD Ports.  There's a
sample worth looking at, but that should NOT be linked to as any sort of
"default configuration."