On Mon, 2008-12-15 at 11:40 +0000, Rachel Willmer wrote: > Thanks for the reply. > > Unfortunately the egg gives me the same problems as when I attempt an > install from the tarball. > > Any RHEL users out there encountered this problem and fixed it?
Whilst I use similar vintage RHEL boxes with at least one client, I don't use MySQL on them, so this hasn't been an issue for me. However, there's a larger issue at play here and, if you've got support for RHEL, you should consider bringing it up with Red Hat: the reason Django does not allow 1.2.1 prior to p2 is that it has a very serious threading bug that causes crashes. Django managed to hit that bug and there are details in our Trac if you, or somebody looking at that, wanted to spend time searching amongst older closed tickets. *Nothing* should be using it unless the mysql-python package been specifically patched to work around that. You should check to see if it has been patched by the vendor (RH) to avoid that problem. In an unpatched state, it's simply a broken package containing a showstopper bug. If it has been patched you *might* be able to just remove the version check in the mysql backend of Django and things might just work (run Django's test suite to check). To maintain version compatibility, Red Hat often don't change the reported version number when they do backpatch a package, which isn't unreasonable, but it does mean something doing version checking (which is the most practical solution for the other 97%) is going to raise a false negative. It's been a while since I dived into the internals, but, from memory, 1.2.1 was more or less identical, internally, as far as the API went, to 1.2.1p2 and we don't do anything beyond using the public API. Aside from that, you're just in the "normal" situation here with long-lifetime, stable systems. Software that is younger than the packaging date of your system version sometimes depends on more recent versions, which themselves depend on more recent versions, etc. Django does a pretty good job of being flexible and accommodating with respect to maintaining older support, and even we have to draw the line somewhere (we spent 18 months, and a lot of care, phasing out support for MySQL-python < 1.2.1p2, in order not to disrupt too many situations). A lot of other releases aren't willing, or possibly able, to be that gentle. Finally, it's not clear what you meant when you wrote "other file versioning problems". If you can get the wrapper to compile (it should only need the mysql-client libraries to build against and anything back to late MySQL 3.x works with mysql-python, again, from memory), then you can install it locally somewhere and set your Python path to pick up your local copy before the system one. It sounds like you're trying to upgrade the system-installed rpm, which is usually not a great idea on a system like that (not just because it usually invalidates support contracts, but because it makes future maintenance harder). Local installs are preferred. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
