Coping with unfinished upstream package split for unixODBC

[Toshio Kuratomi]

Sounds like this is just going to occur for RawHide, right?  With that in
mind....

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)
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.

> 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.
> 
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.

How does this sound:
* Go ahead and build with both the old and new tarballs in RawHide for now.
* If upstream gets to the point of releasing or where you feel comfortable
  shipping a snapshot, go ahead and submit a new package based on that.
* If we get to alpha without having reached that point pull the old tarball
  out of the unixODBC package and submit it as a separate package.  That way
  we're not stuck with shipping F17 with the two unrelated tarballs from the
  same SRPM.

-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/20111202/fda54576/attachment.bin