Contributions helper

RT Developers
1

Hi Jesse and all,

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.

First thing that this utility would do is variable substitution:
so that the main RT installation and the installed add-ons would
reference the same version of Perl, the same RT lib, etc, and bin
paths, and (possibly) the same database access mechanisms.

The second nice-to-have task is much more complicated:
a kind of package management. The most complexity would be in
the sources version control, because most of the add-ins
need to modify some files in the installation.
Perhaps it requires a kind of integrity control with
checksums, in order to ensure that the patches are applied correctly.

With regards,
Stanislav

P.S. I wish you nice Holidays, by the way :slight_smile:

2

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.

First thing that this utility would do is variable substitution:
so that the main RT installation and the installed add-ons would
reference the same version of Perl, the same RT lib, etc, and bin
paths, and (possibly) the same database access mechanisms.

Theres really four generic types of contributions.

Firstly, the ScripActions, ScripConditions and extra pages within the
WebRT directory. These wouldn’t require any assistance from such a tool,
as they all (should be) within the RT library scope and called using the
RT API methods by RT itself. ( ie, ‘use lib’ shouldn’t occur within a
RT::Action, RT::Condition or any file under WebRT/html ).

Secondly, standalone scripts that use the RT libraries. These do need
substitutions of RT library paths, but thats it. The rest of the RT
infrastructure takes care of the mundane tasks such as talking to the
database etc.

Thirdly, scripts which manipulate the database directly. You probably
don’t want to attempt to change those script’s ideas about where libraries
are.

The second nice-to-have task is much more complicated:
a kind of package management. The most complexity would be in
the sources version control, because most of the add-ins
need to modify some files in the installation.

And Fourthly, localised changes to the RT libraries or existing webpages.
For the latter, RT currently defines a separate directory (see
$MasonLocalComponentRoot), where localised overrides to the page can be
placed, with (I assume) your own version control. for the former, the
next version of RT has a similar ‘Overlay’ concept, which allows localised
changes to libraries to be in separate files, again with your own version
control.

However, to address the ‘package management’ issue, you could always use
CPAN, which

Perhaps it requires a kind of integrity control with
checksums, in order to ensure that the patches are applied correctly.

does keep checksums and etc.

P.S. I wish you nice Holidays, by the way :slight_smile:

I’m on-call at the moment. What is this strange ‘holiday’ word people
keep referencing? :wink:

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
3

Hi Bruce,

Thanks for the good explanation. I think it must be put into
RT/FM, for the history.— Bruce Campbell bruce_campbell@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?

4

Bruce Campbell wrote:

Firstly, the ScripActions, ScripConditions and extra pages within the
WebRT directory. These wouldn’t require any assistance from such a tool,
as they all (should be) within the RT library scope and called using the
RT API methods by RT itself. ( ie, ‘use lib’ shouldn’t occur within a
RT::Action, RT::Condition or any file under WebRT/html ).

The accompanying insert_action/condition scripTs, however, do require
munging.

I’ve been half contemplating writing a “generic” insert_addon scripT
but haven’t yet been bored or motivated enough…
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

5

I’ve been half contemplating writing a “generic” insert_addon scripT
but haven’t yet been bored or motivated enough…

Something like that would be useful. you run it against a datafile which
contains:

	%Users
	%Groups
	%ScripConditions
	%ScripActions
	%Scrips
	%Templates
	%Queues
	%CustomFields

or some subset thereof and it does the right thing. Hey. wait a minute.
RT3’s initdb does that, except it’s hardcoded for a standard datafile.
I bet it would be < 10 lines to allow it to take a datafile. I’ll take
a patch.

»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

6

Jesse Vincent wrote:

RT3’s initdb does that, except it’s hardcoded for a standard datafile.
I bet it would be < 10 lines to allow it to take a datafile. I’ll take
a patch.

Untested, as I have yet to dive into RT3, but…
(it’s somewhat more than 10 lines of diff on account of moving
some 310 lines from one file to another :slight_smile:

This may not even run, let alone do the right thing – but it’s
a starting point…

initdb --datafile=file (default:- $RT::EtcPath/initialdata)
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

rt-datafile-patch (24.5 KB)