Bug#690458: RM: blcr/0.8.2-15 testing
On 14 October 2012 17:07, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sun, 2012-10-14 at 16:26 +0100, Adam D. Barratt wrote:
>> Control: tags -1 + moreinfo
>>
>> On 14.10.2012 16:09, Ben Hutchings wrote:
>> > blcr is not usable with kernel version 2.6.39 or later (see bug
>> > #638339). It will probably be fixed upstream at some point, but
>> > it cannot now be released in wheezy. Therefore please remove
>> > from testing only.
>>
>> As mentioned at the BSP, the library has several reverse dependencies.
>> Do we know whether dropping the kernel module and keeping the libraries
>> would work? (CCing the maintainer).
>
> I'm not familiar with the package but from the description it appears
> that the library is only an interface to the kernel module, thus it
> won't be usable with current kernel packages.
>
> The changelog states that:
>
> * blcr-dkms still lacks support for 2.6.39/3.x kernels, but is useful to:
> - Users running newer kernels with stable
> - Users running older kernels with testing/unstable
> - Developers working on support for newer kernels
>
> However I don't think that any longterm kernel series older than 2.6.39
> will be supported for the lifetime of wheezy. Further, userland
> packages in jessie will be allowed to assume a kernel version of 3.2 or
> later, so the next upgrade may fail badly.
>
> If the interface between the library and kernel module is stable (though
> I suspect not...) then the library might be usable with an updated
> module when that arrives. Then it would seem reasonable to include the
> library only in wheezy. But if not then I don't think either belongs in
> the release.
>
> [...]
>> # Broken Build-Depends:
>> mpich2: libcr-dev
>> openmpi: libcr-dev
>
> These can be built without libcr, and indeed they are on those
> architectures where it is not available.
The library behaves sanely without the kernel module and dropping just
the -dkms package would be my preferred solution. Most binaries that
use BLCR are built to run in environments where the presence of the
kernel part isn't a given. Upstream doesn't have funding at the moment
to add support for newer kernels (they sound like it's something they
hope to return to though) and my attempts at developing a patch were
largely unsuccessful, i.e. worse than no patch at all.
I anticipate that the library itself ought to be useable when such a
patch arrives.
There's a bug outstanding for dropping the Recommends to Suggests on
the kernel module, that combined with removing the -dkms package
should be sufficient for releasing without storing up pain for the
future in my view.
Alan
Reply to: