Issues

We do not recommend that you setup new ChiliProject instances and
we urge all existing users to migrate their data to a maintained
system, e.g. Redmine. We will
provide a migration script later. In the meantime, you can use the
instructions by
Christian Daehn.

The current Gemfile restricts the sqlite3-ruby gem to below 1.3; a quick search on this website did not turn out any explanation as to why this is so.

The problem is that v1.3 of the sqlite3 gem is the one that introduces correct string encoding handling, which means that for all prior versions, as far as rails is concerned, sqlite3 only outputs ASCII-8 strings. This is not a problem in ruby18, but in ruby19 any page extracting any non-ASCII-7 character from the database will then trip up the ERB templating system with a cryptic error message that does not mention the database at all.

The fix is easy, since sqlite3 v1.3 and above honor the Encoding.default_internal property; I have sent a pull request to chiliproject at github with a fix.

History

I'm not sure, why we stick to sqlite3 < 1.3. I think it is related to 1.8.6 support. But since, we are no longer support 1.8.6 with ChiliProject 2.0, it might very well be, that the reasons to do so, have vanished.

So I see 2 options here.

1. Your proposed solution to use a newer version on Ruby 1.9

2. Remove the limitation and make it work for all Rubies.

Actually I would prefer the second, but I currently do not have the time to run the tests on at least 1.8.7 and 1.9.2 with sqlite3 1.3.3. Also it would be great, if it would not totally break on JRuby 1.6.x

If there are reasons, why we need to go with option 1, I would prefer, if you used the platform mechanism of bundler-. This way, bundler will be aware of platform differences and can resolve dependency cross-platform, but install only for the local one.

Target operating system is currently Debian Stable [i.e. Lenny --Holger]. This may result in the needto use older versions of some gems, than technically possible. This is mostnotably the following gems

This way, bundler would be able to properly resolve versions for all dependencies. But as I said, it is not possible to express things that way. The only option would be to use the initial approach, proposed by Gary Verhaegen. On the other hand, this is generally not desirable. See the bundler FAQ for a discussion - there it is explained for groups, but the same goes for platforms. Whenever we are hiding dependencies with conditionals, we are running into new kinds of problems.

I was able to install sqlite3 1.3 properly on Debian Squeeze (with RVM), so technically, there seems to be no reason to stick to 1.3. The only one would be, that the system's gem (installed via apt-get) would satisfy the requirement and bundler would not try to install a newer version. This might save you from installing build tools on your app server.

So to put it another way: I'm not able to fulfill Eric's request, without hurting bundler's basic way of doing things. I, personally, would not face any disadvantages from updating to sqlite3 1.3, since I am generally avoiding the package maintainers versions of ruby and gems anyway, and the gem seems to build fine on Debian Stable.

Again. I'm giving up on this issue. I'll let smarter people - having more experience in installation and dependency management - decide.