Re: [Discuss-gnuradio] 'Can't Avoid' fixes in current GNUradio 3.7.9.2

[Tom Rondeau]

On Thu, Apr 28, 2016 at 3:31 PM, Lamar Owen <address@hidden> wrote:

[Reply comments in-line.]

On 04/28/2016 01:41 PM, Marcus Müller wrote:

It's not about not updating – it's about not breaking possible existing
usage! RH has to make sure that software stays binary-compatible, so
they can't use a different version if it has a different ABI.

I not only am aware of the policy, I agree with the policy, and am attempting to work within the framework established by the policy.

GR changes ABI between revisions, and if you change ABI, you're expected
to offer a "-compat" package, even for EPEL.

Hmm, the ABI changed between 3.7.5 and 3.7.9?  Is there a document somewhere that documents the criteria for what consitutes major versus minor versus releases?  In my humble opinion, and going from historical experience with a package that I maintained for five years, an ABI change should be a major version thing, or a minor version thing but not a revision thing (I read the version number of current stable GNUradio as major version 3, minor 7, revision 9, release 2; am I reading that wrong?).  I base my impression on PostgreSQL; 7.0 to 7.1 was an ABI (and database format) breaking change; 7.0.0 to 7.0.1 was not (and I maintained RPMs of those specific versions, up until the beta period for 8.0).  Am I wrong when thinking this with GNUradio?

Yes, if there is an ABI (or an API) change then that's a different ball of wax.

You can see the criteria we have for our version numbering here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets

 

And we have never promised or provided ABI compatibility. We embed the version into the name of the libraries, though, for people to explicitly link to the version they need, such as libgnuradio-runtime-3.7.9.2.so.

...
Central question here is why *you* can't live with 3.7.5; actual user
necessity be the main thing that someone might consider a reason that
"can't be avoided".

And that's the crux of my question: concisely, are there any 'you really need to update and can't avoid it' changes between 3.7.5 and 3.7.9?  If not, then there's no reason I can't use 3.7.5, really. That's part of the reason I'm working with CentOS 7 AArch64 on the ODroids to begin with, as I want to be consistent.  And if 3.7.5 is fine, then I can do that on all my C7 boxen; if there is a compelling reason to go to 3.7.9.2 then I will want to be consistent there, too.

I would think "probably not" within the 3.7 API version series. There have been plenty of additional features and bug fixes, but whether or not they are critical depends on your needs and applications. But I'd say the burden of proving "can't avoid" is pretty high.

You can look through that link I pasted above where we catalog the changes in all of our releases to see if anything sticks out at you, though.

Tom

 

Really, CentOS 7 is pretty stable distro. If you need a version that
they don't offer, your best option probably really is to do the rpmbuild
dance, building your binaries from a modified SPEC file that uses the
GNU Radio source code version of your choice.

And I know how to do that if I need to do that.

Thanks for the good answers, Marcus.