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
Attachment:
pgp5xQo_fzhoz.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
