I've been getting some requests lately to update unixODBC to 2.3.x from the 2.2.14 that we currently ship. AFAICT, the core interface libraries are ABI-compatible so dropping in the new versions shouldn't be much of a problem. The sticky part is that upstream decided to separate into two projects, core libraries and GUI bits, and unixODBC 2.3.x contains only the core libraries. The GUI stuff exists only as a sourceforge project that hasn't yet put out a formal release. So if I just push 2.3.x as-is, the ODBCConfig application goes away, as do the GUI capabilities of odbcinst, or anything else that might call SQLCreateDataSource() or SQLManageDataSources(). This is probably not cool (although maybe nobody really cares about those things? Personally I just hand-edit the odbc config files ...). I know that some people faced with this situation would just grab an SVN pull on $random-date and ship it. Personally I'm not comfortable with that, especially since I know upstream's in a bit of flux at the moment. What I think makes more sense is to continue to build the GUI bits from the unixODBC 2.2.14 tarball, until such time as there's a real release to base a new GUI package on. They should be fully compatible with core libraries built from 2.3.1, so there's no problem from that angle. There are a couple of ways I could go about it: 1. Include the older tarball in the SRPM for unixODBC, and just build it in a subdirectory, and then throw away the installed files I don't want. This would be a little bit messy but would have the advantage that the outside world perceives no change in the contents of the unixODBC package. 2. Create a separate new package to contain the old stuff. This is probably cleaner, but I'm loath to go through all the new-package pushups for something that's likely to have a lifespan measured in months. In particular, package review work on this would be largely wasted effort, since it would be essentially the existing unixODBC package with some output files removed. It would make sense to have a package review cycle whenever the new upstream project produces something we want to integrate, but not now, IMO. Any comments, or other ideas about what to do? regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
