Rare project developers

[Alexander Gall <>]

On Fri, 22 Jul 2022 15:37:09 +0200, mc36 <> said:

> hi,
> On 7/22/22 14:59, Alexander Gall wrote:
>> On Fri, 22 Jul 2022 14:40:01 +0200, mc36 <> said:
>> 
>>> On 7/22/22 14:37, mc36 wrote:
>>>> they're on a 2 release / year schedule now
>>> 4 / year :)
>>> and they're at 20 now, that is, (20-14)/4 = 3 years old jre what we're 
>>> talking about!
>> 
>> I know you're very sensitive about always using the newest code of
>> everything. I don't say this is bad but it doesn't mean that all older
>> code is always inferior. If there are no missing features, security
>> bugs or performance issues, I don't see a need to upgrade just for the
>> sake of it.
>> 
> well, so most of the time it have the benefit of having something that is 
> believed the best one...
> it contains tons of more fixes compared what debian stable have: the 
> cherry-picking the cve
> bugfixes from upstream git and applying them to the frozen version...


>> But since I'm mainly concerned about the SDE, I can offer you to use
>> the newest version of nixpkgs for freerouter. This means that we will
>> be using a separate package collection for the SDE. The only drawback
>> is that it will use more space in the Nix store for all the
>> non-overlapping components.
> hmmm... not a bad start... :) so having the jre is exclusive to freertr
> in the image imho, so the duplicates will be the native's libs: openssl, 
> and friends....

It's more than that because each version of nixpkgs is completely
self-contained and includes everything down to a bootstrapped version
of the compiler. Different versions of libc, for example, will result
in a very large overall difference in packages.  But I don't think we
really have to worry about the footprint on disk very much.

>> 
>> 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.

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
that come natively with nixpkgs to make them work with the SDE:
https://github.com/alexandergall/bf-sde-nixpkgs/blob/master/overlay.nix

I will have to revisit all of that when I change the nixpkgs
version. The reason why I need these tweaks is simply because Intel
bases its build procedure on particular versions of some Linux distros
which differ from what nixpkgs supplies and those differences change
when I change the nixpkgs version. You don't have to deal with that
problem when you only want to build the latest SDE and use one of the
OS supported by Intel. This is the price we have to pay to have an SDE
that is self-contained and works on *any* Linux distribution (as long
as Nix/nixpkgs can be installed on them).

freerouter is much simpler in this respect, hence it's much easier to
track updates to nixpkgs. Using a separate version of nixpkgs from
that used for the SDE allows us to do that. I didn't consider this up
to now because I didn't see a compelling need for it.

I hope this makes my resistance a bit easier to understand :)

-- 
Alex