sotrry, corrupted the original pull request found here: #1061
[LINUX] Enable separate 32/64-bit libraries for linux addons
There is no need for this. Just like ubuntu and all of the other major distros, the addon you get will depend on the repo you get it from. ie you don't 'apt-get install firefox-amd64', you 'apt-get install firefox' and your distro knows that you're running am64, so it fetches from that repo.
If you installed an amd64 xbmc, the distro should either bundle a repo addon that provides addons for your arch, or provide you with packages for the addons themselves.
Otherwise things would get out of hand very quickly.. x86/x64/arm/mips/new x32 abi/, etc.
In addition, an addon for one distro may not work with another due to changes in deps, paths, etc.
The other OSs have stable abi's and we're in control of shipping binaries. For Linux, we just have to accept that it's different and cater towards the distros.
Let's take two examples, ubuntu and openelec.
Ubuntu ships in many abis and many versions. addon-foo.so may work on Precise because it depends on systemlib-bar.so.1, but Quantal only supplies systemlib-bar.so.2. So already, you need 2 versions of the addon. Now, you need to build for amd64/x86/arm. So we're up to 6 versions.
In this scenario, the distro (Ubuntu) should build the addons and create additional packages for them, so that they can be fetched via apt-get. apt-get xbmc-pvr-foo. This way, addons update just like any other system package.
Now for openelec:
Afaik, it does not include any kind of package manager, so apt-get is out of the question. However, it builds for limited abis. In this case, for the x86 build (for example), openelec should add a repository.openelec.pvr-addons-x86 (et al), which provides the addons to it users.
It's complicated, but it's really the only way that makes sense for Linux.
You are absolutely correct as far as package installs are concerned.
However, there are other ways of installing binary addons (manual and addon repository). In these cases, it is probably much more user friendly to have both libs in one package.
The systemlib-bar.so.? problem can be addressed by static linking and compiling on a safely old system. I have done this before for the fishBMC visualization addon, and it worked just fine. But I always had to trust the user to download the correct version.
But - considering the fact, that I am probably the only developer to profit from the change - and not for long, as I really hope fishBMC gets pulled into xbmc - the benefit of this feature is probably negligible.
could you have a look at this and see if we are interested in this?
I agree with theuni, we don't need this. We use proper packaging also for binary addons.