[Pkg-exim4-users] order of file concatenation

[Ross Boylan]

On Wed, Dec 21, 2005 at 08:57:03AM +0100, Marc Haber wrote:
> On Tue, Dec 20, 2005 at 03:00:34PM -0800, Ross Boylan wrote:
> > On Sun, 2005-12-18 at 19:35 +0100, Marc Haber wrote:
> > > On Fri, Oct 07, 2005 at 10:21:30AM -0700, Ross Boylan wrote:
> > > > I started with
> > > > 30_exim4-config_remote_smtp
> > > > 30_exim4-config_remote_smtp_smarthost
> > > > 
> > > > And wanted to add a bit after the remote_smtp transport.  So I created
> > > > 30_exim4-config_remote_smtp_rb
> > > > but this ended up *after* the smarthost stuff.
> > > 
> > > Actually, the idea behind the filename is order_source_name, with
> > > source being "exim4-config" for files installed from exim4-config.
> > > That way, one can easily say where a file comes from.
> > > 
> > > So, you should probably be naming your files like order_local_name. In
> > > any case, I would choose the order number in a way that this forces
> > > the sort order of files. Since transport order doesn't matter, all our
> > > files are at order 30.
> >
> > So, make no assumptions about the relative ordering between files that
> > have the same order number?
> 
> No. As Andreas said, the order is defined by ls and its configuration.
> 
> > This does mean that the trick I was trying to do of modifying an
> > existing transport can't be done reliably,
> 
> Why? The order of transports in the config file doesn't matter.
> 
I was trying to add material after a particular transport.  The order
of transports doesn't matter, but the order in which the files are
concatenated affects which transport my snippet appears after.

Generically (I'm not on an exim4 system now),
30_exim4-config_remote_smtp is
remote_transport:
	optiona = vala
	optionb = valb

I wanted to add 30_exim-config_remote_smtp_rb
        optionc = valc
	optiond = vald
so that these options went after the standard ones for
remote_transport.  My options were for transport-time header rewriting.

However, since the ordering of files within the 30_ is defined by ls,
I happened to get optionc and optiond added after
remote_smtp_smarthost.

In general, if I want a snippet to appear after another one I should
use a higher number, e.g. 31_local_remote_smtp.  But this only permits
modification of whichever transport is last in the list of 30_*.  If I
want to modify an earlier one, I'm out of luck.

Furthermore, the ordering of files within 30_*, if I understand the
above remark about ls, is not dependable.  It is not necessarily
alphabetical, and it is not necessarily fixed.  Some filesystems may
show the files in one order and then, after the file is modified and
potentially rewritten, in another order (I think).

As I said, adding options to an existing transport is probably pretty
unreliable even if the sequencing issues weren't a problem, because if
the main transport changes the options may not be right anyway.  So I
don't think this is a case that deserves to be catered for.  But
perhaps now you can see what I was trying to do.

A final irony is that since my original efforts I've switched to using
smarthost.  Also, it might be possible to accomplish my original
goal using the correct debconf options.