Bug 1172820 - Update to 1.2rc2, split into speex and speex-dsp
Summary: Update to 1.2rc2, split into speex and speex-dsp
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: speex
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1172829
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-10 20:15 UTC by David King
Modified: 2014-12-15 07:47 UTC (History)
1 user (show)

Fixed In Version: speex-1.2-0.1.rc2.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-12 15:57:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
proposed patch (54.94 KB, patch)
2014-12-10 20:20 UTC, David King
no flags Details | Diff

Description David King 2014-12-10 20:15:38 UTC
With the release of 1.2rc2, Speex was split into two tarballs: speex and speexdsp:

http://www.speex.org/downloads/

It would seem best to have the speex package continue to use the speex tarball, and to add a new package for speexdsp.

There is an unfortunate circular dependency between the two packages:

* speex optionally depends on speexdsp
* speexdsp requires the headers from speex-devel to build (but does not link to libspeex)

It seems like the easiest way to avoid problems while bootstrapping is to provide a build conditional.

Comment 1 David King 2014-12-10 20:20:01 UTC
Created attachment 966958 [details]
proposed patch

This should only be pushed once a speexdsp package is reviewed and ready to build.

Comment 2 David King 2014-12-10 20:55:30 UTC
I filed a review request for speexdsp as bug 1172829.

Comment 3 Miroslav Lichvar 2014-12-11 08:15:16 UTC
I don't know, is having two separate packages worth the extra bootstrapping step? They have the same upstream source and possibly will be released together, why not keep them in the same package and just create a new subpackage?

Comment 4 David King 2014-12-11 10:02:59 UTC
I think that the extra bootstrapping step is fine, as combining the two tarballs into a single package seems like it would bring additional problems, such is if there was ever a non-simultaneous release (which I suppose would lead to some awkwardness with mismatched version numbers).
I also think that the legibility of a combined spec file would be worse, with having to configure and build twice, making sure to inject the include path for the speex headers into speexdsp, and so on. I would like to avoid handling speex linking to the uninstalled speexdsp, as well.
Either way, splitting the libraries between two (sub-)packages will probably be the most disruptive change.

Comment 5 David King 2014-12-11 14:15:50 UTC
The review of the separate speexdsp package was approved in bug 1172829. If you prefer to go with the split package route, rather than the subpackage route, I can file the SCM request and coordinate the builds (I have speex commit access via the gnome-sig group).
If you would prefer to go the subpackage route, I can come with an alternative patch for the speex package.

Comment 6 Miroslav Lichvar 2014-12-11 14:20:55 UTC
It's ok, commit the patch for the split. Thanks.

Comment 7 David King 2014-12-12 15:57:39 UTC
Split speexdsp and speex packages pushed and built for Rawhide. I have not made and changes to F21 or below, and I think it is probably best to leave those branches at rc1 (before the split) to avoid any problems it might cause, or at least delay any bumps until problems are shaken out in Rawhide.

Comment 8 Miroslav Lichvar 2014-12-15 07:47:08 UTC
Great, thanks!


Note You need to log in before you can comment on or make changes to this bug.