Build-Depends-Indep is useless

The words in the title are not mine, but only a quote from Debian Wiki.

However, if you're reading a debian/control file and wondering what Build-Depends-Indep means, starting from the assumption that it is useless may help.

Otherwise you can follow the rule to put in Build-Depends all those packages that are absolutely necessary to build architecture-dependent files, while the rest goes into Build-Depends-Indep.

Use the Warnings, Luke

Browsing StackOverflow on perl-related topics, I have two main considerations:
1. Answers are typically very good, concise and useful
2. Questions are submitted with code that doesn't have 'warnings' enabled

I'd say that a considerable portion of the questions submitted would not be posted, or would be less generic, if authors used 'use warnings;' in their code.

Then add a pinch of the great perl critic, and possibly only half of the questions would really be submitted.

If you're using perl, or plan to use it, I strongly recommend to:
1. Always set 'use warnings;'
2. Always submit your code to perl critic (and keep a copy of Perl Best Practices handy).
3. First create the tests, then write the code. That's the only reasonable way (unless you're working on a one-liner for a quick admin task). TDD is your friend.

See more on Perl Critic here.

debian - cleaning up stale configuration files

As suggested in Debian Cleanup Tip #1: Get rid of useless configuration files, it's worth using grep-status to retrieve information about configuration files left behind a package removal or upgrade.

For example, on my Squeeze VM:

$ grep-status -n -sPackage -FStatus config-files
libjack-jackd2-0

You can confirm with 'dpkg -l' that's a package in 'rc' status:

$ dpkg -l | grep libjack-jackd2-0
rc libjack-jackd2-0 1.9.6~dfsg.1-2 JACK Audio Connection Kit (libraries)

You may probably want to remove definitely those configuration files; just purge the package. For example:

$ dpkg -P libjack-jackd2-0

See also about debian configuration files, an important assumption Debian takes.

Recommended tool: Putty Session Manager

If you have more than a few entries on putty, you may consider using Putty Session Manager.

You can organize your sessions in folders (and start all the sessions inside a folder with a click).

Please leave a comment if you know something better!

debian, tab completion failing

Not a big deal, but since the solution to this problem wasn't immediate to find, it's probably worth writing it down.

Symptom: when you try to tab complete a command, you see a message like this:

vi /et-sh: <( compgen -d -- '/et' ): No such file or directory

Cause: You're using sh, not bash, so even if tab completion is enabled on ~/.bashrc, it won't be available to you.

Solution: change the default shell for the current user from sh to bash with

chsh -s /bin/bash

That's it.

Inside-Out Objects for Perl – I’m not convinced

When I’ve found Inside-Out Objects not only mentioned but suggested inside Perl Best Practices (see "Always Use Fully Encapsulated Objects" section) I thought: “Cool, here’s a solution to enforce encapsulation on Perl classes. This was badly needed”. But then, the list of advantages wasn’t too exciting, while the drawbacks were quite scary… See for example this analysis.

To simplify the problem, note that all I want is: “a mechanism to prevent an object attribute to be read or changed from outside the object”. In Java, C++, PHP, you just declare that class attribute as private. Simple. (Python has a form of “privatization by obfuscation” that I don’t really like, but it may be better than what Perl does – which is nothing).

Perl (5) is not a full OO programming language, just a procedural language that has got some additions to allow for OO dynamics, but still I'm surprised I can't "protect" object attributes... Getting back to Inside-Out Objects, the best analysis I’ve found is from perlmonks in 2005.

I agree with the points raised by jhedden (however I find points 1, 2, 3 and 9 “less strong” than the others):

1. Hash-based objects are the standard. Using a different object API may lead to maintainability issues.
2. Inside-out object classes aren't compatible with hash-based object classes.
3. Inside-out objects are just another kludge on top of Perl's already kludgy OO mechanisms.
4. I haven't had any problems using hash-based objects. The encapsulation and compile-time checking advantages of inside-out objects aren't important enough to induce me to use them.
5. The encapsulation provided by inside-out objects is unenforcable because the source code is available.
6. Inside-out objects require a DESTROY method, and I don't what to have to remember to write one each time I create an inside-out class.
7. There are too many alternative inside-out object support modules that aren't compatible with each other.
8. I'm leery of the 'magic' the inside-out object support modules do 'under the covers'. There may be bugs or they may lead to unexpected problems when interacting with other modules.
9. I tried module Foo::Bar, and had problems with it so I gave up on trying to use inside-out objects.
10. You can't serialize inside-out objects either in general, or using Data::Dumper or Storable.
11. Inside-out objects are not thread-safe because they usually use refaddr as the key for storing object data.

I was hoping perl 6 will eventually solve the problem of private attributes (which is all I want here) and it seems I’m lucky:

Attributes are defined with the has keyword, and are specified with a special syntax:

class MyClass {

has $!x;

has $!y;

}

The ! twigil specifies that this variable is an attribute on an object and not a regular variable.

Attributes are private, but you can easily add an accessor for it, that is a method of the same name that can be called from the outside of the class and returns the value of the attribute. These accessors are automatically generated for you if you declare the attribute with the . twigil instead:

class MyClass

has $.x;

has $.y;

}

When you assign to an attribute from within the class, you still have to use the ! form.

Do I like that syntax? I do not. Do that mechanism satisfy my need? Yes, thank you.

Another reason to look forward to Perl 6.

Test reports on Hudson in 30 seconds (well, let's say quickly)

There are so many articles on how to generate test reports on Hudson for perl modules or applications, that I thought it was somehow complicated. It's not.

The underlying problem is that Hudson has support for test results in JUnit format. To solve this you need to convert from TAP to JUnit the test results.

Of course there are some pre-requirement:

• Your perl code must have tests (duh)
• You must have Hudson set up to run those tests
• You need to install TAP::Harness::JUnit on the building box
• You need to install 'prove' on the building box

Then all you have to do is add this command in the shell script you execute to run the tests:

prove --harness=TAP::Harness::JUnit

and configure the "Publish JUnit Test Result Reports" section of your project to point to the resulting XML file.

No mumbo jumbo.

Since TAP::Harness::JUnit is not available as a debian package, if you need to install it properly, just follow the usual procedure to generate debian packages from CPAN modules:

1. wget http://search.cpan.org/CPAN/authors/id/L/LK/LKUNDRAK/TAP-Harness-JUnit-0.32.tar.gz
2. tar -pzxvf TAP-Harness-JUnit-0.32.tar.gz
3. dh-make-perl TAP-Harness-JUnit-0.32/
4. cd TAP-Harness-JUnit-0.32
5. debuild

There you go.