Local customizations: debian packaging?

Greetings all,

We’re moving toward debian packaging all our in-house software for
internal (and, occasionally, external) distribution.

Our local customizations of RT, however, pose a bit of a problem–random
bits and pieces all over the place!

Anyone come across this problem before? Ideas? Suggestions?

Thanks,

Jens

Our local customizations of RT, however, pose a bit of a problem–random
bits and pieces all over the place!

Anyone come across this problem before? Ideas? Suggestions?

I don’t entirely understand the problem. Debian’s packaging system is
more or less designed to handle files going all over the place.

What sorts of bits and pieces are causing problems, exactly?

jeff

Our local customizations of RT, however, pose a bit of a problem–random
bits and pieces all over the place!

Anyone come across this problem before? Ideas? Suggestions?

I don’t entirely understand the problem. Debian’s packaging system is
more or less designed to handle files going all over the place.

point taken.

What sorts of bits and pieces are causing problems, exactly?

Perhaps I’ve asked too soon. It’s been six months and more since I last
was working on our local customizations, but things like cron jobs for
the rt user, overlay stuff, etc, etc. I’m sure I’ll think of more later.

Problems of upgrading versions also come to mind.

Because local stuff doesn’t tend to have a cohesive whole–it’s bits and
pieces everywhere that, in themselves, are completely meaningless. Sure,
you can declare a dependency to a particular version of RT, but you get
my drift, right?

Has anyone else had this requirement, and, if so, how have you approached it?

Jens

What sorts of bits and pieces are causing problems, exactly?

Perhaps I’ve asked too soon. It’s been six months and more since I last
was working on our local customizations, but things like cron jobs for
the rt user, overlay stuff, etc, etc. I’m sure I’ll think of more later.

Ahh, ok, I understand a little better. If I understand you correctly
and you’re actually using the Debian RT package, and want to package
your customizations, then there are some definite things I’d do.

I’d have the your local package depend, of course, on the precise RT
version it was designed to work with. I’d package overlay files, and
any local-specific configuration files that aren’t user-changed.

I’d then setup a config method in the Debian package for any options
your local admins should have. And I’d have a postinst method to do
the final configuration of cron jobs and things that aren’t purely
files.

I’m sorry if that sounds nonspecific. I can’t tell if your a dpkg wiz
(in which case everything I typed is useless, because you knew it :slight_smile:
or whether packaging in Debian is something new for you (in which case
most of what I typed is useless, because the package structure and
capabilities aren’t yet terribly clear).

Hopefully someone else will have use-cases that are useful to you :slight_smile:

jeff

Jens Porup wrote:

I don’t entirely understand the problem. Debian’s packaging system is
more or less designed to handle files going all over the place.

point taken.

What sorts of bits and pieces are causing problems, exactly?

The bits that cause the problem will not be the overlays or cronjobs.
That is all pretty standard.

The problem is things like scrips and custom fields. These exist inside
RT’s database and are difficult to version control / package.

I think that a script that is clever enough to add / modify custom
fields and scrips etc might be the solution.

For simple backup this is not such an issue, just backup the database.

For development it becomes an issue. Currently the workfow here is.

1 Set up a devel RT instance.
2 Copy production DB into the dev instance.
4 Muck around with custom fields, scrips, permissions etc.
5 Test - Repeat 4 - 5 till happy
6 Manually move the final changes over to the production RT

I am thinking about something more like.

1 Set up a devel RT instance.
2 Copy production DB into the dev instance.
3 Hack on cusomisation package adding routines to move from old to new
version of customisations
4 Install RT customisation package (on dev instance) which

  • Works out what version or RT customisations are installed.
  • Updates RT customisations to latest.
    5 Test - Repeat steps 2 - 5 until happy
    6 Update customisation package on production.

How do other people do this?

Cheers

Adam Clarke
Strategic Data Pty Ltd

a message of 52 lines which said:

The problem is things like scrips and custom fields. These exist
inside RT’s database and are difficult to version control / package.

Yes, the problem is much more general than packaging. I want to manage
my email templates in our version control system (Subversion) and the
only solution I find is to have a “install” target in the Makefile
which calls SQL UPDATE in the database.

a message of 52 lines which said:

The problem is things like scrips and custom fields. These exist
inside RT’s database and are difficult to version control / package.

Yes, the problem is much more general than packaging. I want to manage
my email templates in our version control system (Subversion) and the
only solution I find is to have a “install” target in the Makefile
which calls SQL UPDATE in the database.

So. there are a couple things here.

  1. Module::Install::RTx is a nice packaging tool to let you build and
    install custom RT extensions as perl modules

  2. Those templates are Text::Template perl objects. Whcih means that you
    should be able to embed in them calls to, say, a perl module or to read
    a file from disk. Which should get you your versioning :wink:

So. there are a couple things here.

  1. Module::Install::RTx is a nice packaging tool to let you build and
    install custom RT extensions as perl modules

That’s very cool–thanks!

But, when I try and install Module::Install::RTx, make test fails:

desktop:~/Module-Install-RTx-0.11# make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e” “test_harness(0,
‘inc’, ‘blib/lib’, ‘blib/arch’)” t/*.t
t/0-signature…WARNING: This key is not certified with a trusted signature!
Primary key fingerprint: 66B2 B78E D1B7 7641 4861 D592 B4B3 DD37 3C35 01A0
Not in MANIFEST: debian/changelog
Not in MANIFEST: debian/compat
Not in MANIFEST: debian/control
Not in MANIFEST: debian/copyright
Not in MANIFEST: debian/rules
Not in MANIFEST: debian/watch
==> MISMATCHED content between MANIFEST and distribution files! <==
t/0-signature…FAILED test 1
Failed 1/1 tests, 0.00% okay
t/1-basic…ok
Failed Test Stat Wstat Total Fail Failed List of Failed
t/0-signature.t 1 1 100.00% 1
Failed 1/2 test scripts, 50.00% okay. 1/2 subtests failed, 50.00% okay.
make: *** [test_dynamic] Error 255

Ideas?

Thanks,

Jens

So. there are a couple things here.

  1. Module::Install::RTx is a nice packaging tool to let you build and
    install custom RT extensions as perl modules

But, when I try and install Module::Install::RTx, make test fails:

Aha!

Methinks dh-make-perl is buggy, and that you are using Module::Build.

Signature validates if you do a manual cpan download, but dh-make-perl
will only work if you specify --no-test.

Jens

a message of 52 lines which said:

The problem is things like scrips and custom fields. These exist
inside RT’s database and are difficult to version control / package.

Yes, the problem is much more general than packaging. I want to manage
my email templates in our version control system (Subversion) and the
only solution I find is to have a “install” target in the Makefile
which calls SQL UPDATE in the database.

So. there are a couple things here.

  1. Module::Install::RTx is a nice packaging tool to let you build and
    install custom RT extensions as perl modules

  2. Those templates are Text::Template perl objects. Whcih means that you
    should be able to embed in them calls to, say, a perl module or to read
    a file from disk. Which should get you your versioning :wink:

Hmmm…

I’ve had a good look at this over several days, but I’m not seeing
exactly how you can embed a Text::Template object into an RT
method call.

Sure, I could leave my template in my perl script, and simply pass my
paramhash of (Content =>, Name =>, Description =>, Queue =>), which
works fine, but that doesn’t give me a separate file I can version from.

So:

    use Text::Template;
    my $source = Text::Template->new(TYPE => 'FILE',  SOURCE => 'my_template.tmpl');

    use RT::Template;
    my $template = RT::Template->new($RT::SystemUser);

    #(use of cat suggested by Text::Template docs)
    my @errs = $template->Create(qx{cat my_template.tmpl}); 

    #returns 0 for failure
    print STDERR "errs is @errs\n";

There doesn’t appear to be any Text::Template method call that can do this
either.

Suggestions?

Jens