Coping with unfinished upstream package split for unixODBC

[Toshio Kuratomi]

On Sat, Dec 03, 2011 at 02:24:08PM -0500, Tom Lane wrote:
> Toshio Kuratomi <a.badger at gmail.com> writes:
> 
> 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?
> 
<nod>  It isn't really about instability, though... it's about getting
updates that aren't needed.  It sounds like the GUI tools in unixODBC-2.2.14
won't be updated, but everytime the library providing tarball is updated (or
new patches are added from the Fedora side), the entire unixODBC package
gets rebuilt and the end user ends up having to update the GUI package.

[snip]

> 
> [ 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?
> 
I think I like this a lot.  It sounds like upstream isn't changing the GUI
tools very fast.  So even if they reorganize the code and build scripts
significantly before release, we might be perfectly fine continuing to ship
a snapshot in the released Fedoras since the code itelf will have seen few
worthwhile changes.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111205/bc3df8f3/attachment.bin