libcdio-1.0.0 breaks audacious-plugins-3.9

[ken@…]

Nothing in the audacious bugs, probably I'm the first person trying to built it with libcdio-1.0.0.

First issue concerns libcdio itself : LIBCDIO_VERSION_NUM has been reset to 1 (it started at 68 in v0.68). That causes the audacious code to look for the headers in the wrong place (they moved for versions >= 90).

I hacked that temporarily, but since we already have a patch for libcdio upstream fixes, I think the better fix is to backport

2d22ae18571caf29460a456340ff0603f04af6b4

    Set LIBCDIO_VERSION in a more consistent way
    
    we'll use the convention
    x.y.zjunk => x*10000 + y*100 + z
    
    Savannah bug #52491

What that *actually* does (in git for 1.0.1) is LIBCDIO_VERSION_NUM=10001

so we could backport that as 100000.

Second issue is that after audacious-plugins finds the headers it falls apart. Something has changed, at the moment I'm not sure what.

[bdubbs@…]

Yes, I made a hack in gst-plugins-ugly for the same reason.

For your hack, I think you mean 10000 not 100000.

You can try adding:

sed -e "/cdtext.h/a #undef LIBCDIO_VERSION_NUM\n#define LIBCDIO_VERSION_NUM 10000" \
    -i src/cdaudio/cdaudio-ng.cc

And see if that works.

[bdubbs@…]

I tested my hack above and it worked for me.

[ken@…]

Replying to bdubbs@…:

I tested my hack above and it worked for me.

Thanks, Bruce - yes to the number, and yes, it builds for me.

I see that gvfs is now giving a problem, so maybe in the end we will change libcdio.

[bdubbs@…]

Replying to ken@…:

Replying to bdubbs@…:

I see that gvfs is now giving a problem, so maybe in the end we will change libcdio.

Agree. That may be easier. I'll wait until I get a response from John. It would also be nice if upstream would release an updated libcdio.

[thomas]

Replying to bdubbs@…:

Replying to ken@…:

Replying to bdubbs@…:

I see that gvfs is now giving a problem, so maybe in the end we will change libcdio.

Agree. That may be easier. I'll wait until I get a response from John. It would also be nice if upstream would release an updated libcdio.

Well, might be easier, but IMHO not really the right way.

The easiest way around this is not to upgrade A.

If need to upgrade A (for whatever reason), it might break other packages B. B must be fixed to be fine with new version, I think upstream will make this fixes anyhow. If not, they may have reasons to not use the new version of A (or B is unmaintained). If there are real reasons in B to not upgrade, tweaking A to look like as an "older" version will break B.

[bdubbs@…]

The problem is that libcdio broke the build of dependent packages by changing (in a header) to a version number 1 (the new major number) when before the number was around 83 (the old minor version number). I checked and upstream has updated the version number in git to 10000 and intend to make the next version (1.0.1) have a number of 10001. This is basically major * 10000 + minor * 100 + point.

The bottom line is that the libcdio devs made a mistake.

In libcdio we just need to do:

sed -i '/^LIBCDIO_VERSION_NUM=/s/=.*$/=10000/' configure

[bdubbs@…]

Fixed at revision 19579.