Rare project developers

[Alexander Gall <>]

On Wed, 27 Jul 2022 15:15:55 +0200, mc36 <> said:

> On 7/27/22 14:01, Alexander Gall wrote:

>>>> 
>>>> I will not consider doing this (i.e. blindly upgrading everything) for
>>>> the SDE. This *will* lead to failures and hard-to-track regressions.
>>>> 
>> 
>>> btw are you sur about it? just asking because my dataplane tester vm
>>> _is_ a debian sid, and the sde works fine as is, since it sandboxes
>>> itself from the system libs... (maybe boost is what installed from apt)
>>> regarding the kernel modules, when my stordis was near me, i ran that
>>> box on stable+backported kernel and up to that point, except about 2-3
>>> times, the module worked fine on the latest-greatest kernel...
>> 
>> I'm not talking about the kernel modules. In fact, the kernel is not
>> part of nixpkgs at all, i.e. it's irrelevant in this context.
>> 
> i mentioned it because the sde except in model mode, one needs to compile
> the 2 kernel modules from the sde... and on major kernel bumps, internal
> api breaks and that was the above all about...

I'm aware of that.

>> The problem is the dependencies of the SDE. Some of them are pretty
>> specific wrt versions, e.g. thrift and protobuf. Some of them need to
>> be built with specific features. The requirements change with
>> different versions of the SDE. Remember that I support all SDEs back
>> to 9.1.1 (and I'd like to keep it that way because it's useful to be
>> able to switch SDE versions when using bf-sde-nixpkgs as development
>> environment).  I've had to make quite a few tweaks to the packages
> first of all, i really don't see the point supporting something intel 
> already dropped support for...
> even for development... just think about what cacerts have in those 
> packages? does it contain the
> new letsencrypt root ca from last winter? without that, half the internet 
> wont load from the nix shell,
> rendering the whole stuff completely unusable.... :)

Nix deals with this by allowing the location of the CA bundle to be
overridden by the environment. In the standard installation we use,
this is done by default. E.g. on a Debian system, Nix will actually
use /etc/ssl/certs/ca-certificates.crt, which can be kept up to date
independently.

> 9.1.1 surely was designed to debian10 or older with it's old kernel,
> so imho the kernel modules from the sde does not compile for the current
> image we're on... simply those old kernel modules dont have the ifdefs
> for the newer kernels...

I would notice if something doesn't compile, don't you think? I
back-ported a few changes from 9.2.0 to 9.1.1 back then for that
purpose.  All SDEs compile and they all work on kernels all the way to
Debian 11.4.

> moreover, once debian12 will be out, i bet you they'll require even newer 
> packages...
> so i believe you that for now you found a point in time when all your 
> current sdes
> compile and do something at least in model mode but believe me, that'll 
> change with
> as time passes by...

Look, you can really leave that up to me as the maintainer of these
packages. When I can support older stuff with minimal effort, I do
so. I also have no problem to drop things when it takes more work than
it's worth. Neither is it a problem to move to a newer version of
nixpkgs at some point (I definitely will). If you find an *actual*
problem (as opposed to speculations or misconceptions, no offense
intended), I'll be happy to deal with it. I haven't seen one so far :)

We can move to a different version of nixpkgs for freerouter, as I
already proposed, to disentangle that from the SDE.

If you don't mind, I would now like to stop going down this rabbit
hole.

-- 
Alex