[rt-devel] contributions helper

[Stanislav Sinyagin]

Hi Bruce, 

Thanks for the good explanation. I think it must be put into 
RT/FM, for the history. 

--- Bruce Campbell <bruce_campbell at ripe.net> wrote:
> On Sat, 21 Dec 2002, Stanislav Sinyagin wrote:
> 
> > I think it would be nice to integrate a small utility
> > into RT distribution which would help to install and
> > (probably) maintain the contribution add-ons.
> 
> You need to be more precise, as there are a number of types of add-ons,
> all of which are somewhat different.

Actually, as I wrote yet only one add-on, and it's an executable script 
which uses RT libraries, that type of add-ons was my main concern. 

I think it's quite boring process: every time I update my script, 
someone who uses it needs to edit those same line, like Perl location, 
and RT paths. 

Currently (2.1.x) configure.ac does variable substitution for all 
files, including Makefile.in and lib/RT.pm.in. That's actually not 
the way the autoconf manuals recommend. 
They do recommend (as far as I believe) to use AC_CONFIG_FILES()
only for Makefiles and a small utility that would replace the variables 
for the rest of the files. Then those makefiles would call this 
utility for all their targets that need the substitution. 

That's actually what I did in http://rrfw.sourceforge.net, 
and it works fine. 

In case of RT, this utility would be useful not only for RT installation 
process, but also for contribution scripts.   


As for the other types of contribs, that's nice that the new RT is more 
adaptated for them. Still, it would be nice to rely on config variables 
like $MasonLocalComponentRoot in the contrib installation process, 
and make this as much automated as possible. 
It only needs some standartization efforts, to force the contrib packages 
to conform some requirements. And a small package management utility 
would do the job of copying the files in the right places.

This would bring us many benefits, like: 
-- harmless contribution packages that don't break the system
-- easier troubleshooting
-- easier way to determine what the heck is running on 
   the site that someone else installed before you
and so on. 

I think I'll have some time during next few weeks for coding 
parts of it, after I get the green light from the community. 

Speaking of autoconf, and once my critics on installation process 
is accepted, what about moving to Automake?
This would solve some issues, like  distribution tarball generator
(now tarball includes both configure sources and the produced output), 
dependencies check (configure would run automatically should it be needed), 
and just because it's a nice product and a great deal of tasks is already 
done?


With regards, 
Stanislav. 

P.S. being on-call doesn't prohibit you a beer or two?