On Thursday 19 November 2009 12:21:16 pm Christian Boos wrote: > Well, it's hard to believe that people wanting to install a recent Trac > version couldn't also take the extra 5 minutes needed to download and > install the pysqlite 2.x bindings, if they're using Python 2.4.
It's yet another 5 minutes, and "it's hard to believe" that it would only be 5 minutes of additional work to figure out what was needed, determine that it was not available for the distro, locate the correct website, download the right version, hunt down the build dependencies, build and package the dependency, and install it. > Concerning the other versions, Python 2.3 support has been dropped and > I'm sure you know that Python 2.5 and upward come with the "sqlite3" > package bundled, so this is only an issue for 2.4. Pysqlite can even > download for you the latest SQLite amalgamation source file for creating > a self-contained binary, when doing a build_static. If CentOS 5 was shipping python 2.3, I would have blocked dropping support for Python 2.3. If you are running the current version of a major enterprise Linux distro, you should not have to upgrade things like python and sqlite bindings to run the current version of Trac. > In case you want to rely on the platform packages exclusively and if you > can't install pysqlite 2.x that way, then you certainly won't be able to > install Trac 0.12, Genshi 0.6 and Babel 0.9.4 that way either. I see those three packages as fundamentally different from sqlite. In particular, those are all edgewall.org projects. My concern was that I want people (including myself) to be able to run Trac on CentOS 5, and did not want to force yet another package upgrade on the process. The more work it is, the fewer people will use Trac. That said, since pysqlite 2 is in EPEL (http://fedoraproject.org/wiki/EPEL), that's enough for me on that score, so I drop my objection. (EPEL also has genshi 0.5.1, babel 0.9.4, trac 0.10.5 for what it's worth.) > Now why did we drop support for pysqlite 1.1.x? > The last version released on the pysqlite 1.1.x branch was 1.1.8, in > 2006. That 1.1 branch is basically an adaptation to SQLite 3.x of the > original pysqlite 1.0 branch which worked with SQLite 2.x. As such, it > shares many of its drawbacks, like poor concurrency behavior. Pysqlite > 2.x was a major rewrite and works much better for Trac. Also, whenever > we have a problem report involving pysqlite 1.0.x or 1.1.x, the first > thing we do is to ask them to upgrade to 2.x, so we can hardly say it's > "supported". > > As the topic of performance improvement gradually became more and more > important, trying to avoid misconfiguration or using "known bad" support > packages is something we should do. Better tell the Trac administrator > upfront that there's some more installation work to do in case all the > prerequisites are not met, rather than let him do a quick install with > problematic packages. Otherwise there will be *more* work afterward when > troubleshooting performance, at which point the responsibility of the > pysqlite 1.1.x package will not be obvious (see e.g > http://trac.edgewall.org/ticket/7785#comment:29 ; ok, that was an > upgrade from 1.0.x but I hope you get the point). Since pysqlite 2 is in EPEL, I'm ok with dropping pysqlite 1 support. That said, these arguments would convince me to _deprecate_ pysqlite 1, explicitly stating in an ERROR-level deprecation message that upgrading to pysqlite 2 is strongly encouraged, and stating that pysqlite 1 support would be dropped as soon as pysqlite 2 was available in CentOS. Fundamentally, for our 3rd-party dependencies, we must support the versions available in the major enterprise distributions' latest release. Failure to do so causes our users pain. Eli ------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram [email protected] `------------------------------------------------- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=.
