Coping with unfinished upstream package split for unixODBC

[Tom Lane]

Toshio Kuratomi <a.badger at gmail.com> writes:
> Sounds like this is just going to occur for RawHide, right?  With that in
> mind....

Right, no intention of changing unixODBC in released branches.

> On Fri, Dec 02, 2011 at 04:22:55PM -0500, Tom Lane wrote:
>> 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.

> I wouldn't want to see this method propogated out to a released Fedora as it
> has end user drawbacks (for instance, the end user having to download and
> install new packages if there's changes for either of the upstreams)

Well, unixODBC 2.2.14 isn't going to change anymore, so I don't really
think that end of it would be adding instability.  In any case, if we
get to the point of doing a Fedora release before upstream gets their
release sorted, I would also think that we'd not track the upstream
release in released Fedora branches.  So AFAICS the only possible extra
churn would be in rawhide.  Do you see other reasons why this would be
a bad thing to be shipping in a released version?

> Since you have a feel for how upstream is coming along in their release of
> the new project for the GUI pieces it could be done in rawhide with a plan
> for how to get away from it by release.

I can't say that I'd want to hold my breath.  The decision to split the
upstream project was taken at the start of 2009, and unixODBC 2.3.0 was
released (minus the GUI bits) in April 2010.  unixODBC 2.3.1 was
released last week, which is not too far off this upstream's historical
release speed.  For all I know, a formal release of the GUI project
could come next week, but it could be a long time, too.

[ goes off and looks at the unixODBC-GUI-Qt sourceforge repository's
commit statistics ]  Hmm ... given the speed with which things are
(not) happening upstream, maybe I should reconsider the idea of just
taking an SVN snapshot.  What's your opinion of that option?

>> 2. Create a separate new package to contain the old stuff.

> In many ways I like this better because it's a more future-proof strategy.
> But I definitely understand your concerns -- we'd be doing a review of the
> split package now, when we only have the old build method from the combined
> tarball.  For better value, we really would rather be reviewing something
> that came from the separated project. So you either have to do two reviews
> or you just review the old package now and let the new tarball replace the
> old tarball when the time comes without passing it through an external
> review.  Neither of those alternatives is that great either.

The risk we'd be taking here (if we review based on a snapshot) is that
upstream might significantly reorganize things before they do make a
release.  However, doing any such thing would require more manpower than
seems to be available, so I think this is somewhat unlikely.

			regards, tom lane