Coping with unfinished upstream package split for unixODBC

[Tom Lane]

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