Hi Eli, Eli wrote: > All, > > In looking to apply a cleaner version of [8817] to 0.12dev, I noticed that we > appear to have completely dropped support for sqlite 1 from 0.12dev in [8571] > as part of http://trac.edgewall.org/ticket/8625 > > CentOS 5 (and therefore REL 5) have sqlite 1 > CentOS 6 and REL 6 aren't out yet. > > So the statement from that ticket that "I think there's no need for a > deprecation period, as hardly anyone would be using it for new installations > or even upgrades." is, sadly, not the case. > > This is going to be a problem for me, personally, as I try to get my various > Trac instances up to date. > > I strongly believe that Trac needs to be able to run on the current major > "enterprise" versions of Linux, and as 0.12dev stands, it won't. > > My Trac development time has been very limited, but I can try to address this > next week. Are there objections to me re-adding sqlite1 support given that > CentOS and REL are still shipping sqlite1? >
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. 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. 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. 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). -- Christian -- 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=.
