I demand that Ville Skyttä may or may not have written...

> On Sunday 17 February 2008, Matthias Schwarzott wrote:
>> On Sonntag, 17. Februar 2008, Joerg Bornkessel wrote:
>>> We detect this in the vdr-xineliboutput-*.ebuild an let install the
>>> xineplug_inp_*.so  to the given dir by the headerfile. There is nothing
>>> wrong.

Yes there is – your detection method.

>>> Jussy, just skip the xine-lib- Version, use an older version, or
>>> i hope it will fixed by xine team, then the next version.

Bad advice, unless the known potential for remote exploits (admittedly
remote, but let's ignore that) isn't a problem for that particular

>> This is fixed in ebuild vdr-xineliboutput-1.0.0_rc2_p20080120-r1. Now we
>> restrict the xine-lib version to 3 components.

That'll be broken again by the next release (I've changed the naming), but
there'll be a benefit: once the plugin is rebuilt, you'll be able to avoid
rebuilding it unless you have need of some new ABI extension.

Or at least that's the plan :-)

(Incidentally, it was unrebuilt vdr-plugin-xineliboutput blocking xine-lib
migration into Debian testing – needed for security fixes – which prompted
this change...)

> FWIW, I'm pretty certain that the only upstream supported way to retrieve
> the dir where to install xine plugins is to use "xine-config --plugindir"
> or "pkg-config --variable=plugindir libxine".

They are, but you should not use pkg-config unless your plugin is not

| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Let's keep the pound sterling

Avoid commas, that are not necessary.

vdr mailing list

Reply via email to