Because you cannot reasonably keep track of all the code you bundle and it's possible vulnerabilities. Distributors cannot and do not rely on a few thousand upstreams to not ship known vulnerable code, for good reason.

Developers should always try to support system versions of any kind of library, because this does not just affect packagers, but regular blender users as well (whether they use a distro-package or not).

if it's defautl to use system LZO, then perhaps install_deps.sh is to be modified as well?

Probably. I just never used that script so I missed it.

We can consider adding a warning that system lzo not found and that bundled one would be used (that would make previous change unneeded)

I personally dislike build systems that try to be too smart. Even the "if lzo not found, disable the feature" thing is in my opinion not nice, but since the rest of the build system code does that too I just went with it for the sake of consistency.
But actually, I'm more pro fatal warnings, so that it's clear some condition could not be met with the given configuration and hence the user knows the build system will never install a different configuration from what he has specified. That's a pretty important point for distributions, so it may be obvious why I prefer that.

For a practical solution... I'd prefer to print a warning if system LZO was not found which says it will be disabled + that the user can switch to the bundled one.

We can make it a job of FindLZO to return hardcoded locations to minilzo for osx/win

What exactly do you mean? I'd prefer to keep the FindLZO module what it is... a generic module, not a blender-specific one.

I don't like the idea of disabling feature if liblzo-dev is not found. It'll be a regression from the builders point of view. Blender is already too complicated to compile, adding just another change which will likely ruin loads folks' days is not good at all.

So imo eitehr we fallback to bundled lzo if system's is not found, or we keep system_lzo defaul off (as we do with, say, bullet).

From the quick glance i don't mind the patches at all. Couple of questions:

What about adding /opt/lib as a hint for the Find*.cmake? Some of blender developers uses it.

Ideally SCons also should allow using system libraries

Would you be interested in creating the branch in our repo where you can commit the patches, work further on making scons aware of the system libraries, maybe add options for decoupling more libraries?

P.S. scons might not do find stuff, config variables like BF_LZO_LIBRARIES and such would eb sufficient to make platform maintainers who uses scons happy.

From the quick glance i don't mind the patches at all. Couple of questions:

What about adding /opt/lib as a hint for the Find*.cmake? Some of blender developers uses it.

Sure.

Ideally SCons also should allow using system libraries

I can't say I am particularly eager to deal with SCons. Why is it still in place? Maintaining two build systems at a time is pretty cumbersome anyway.

Would you be interested in creating the branch in our repo where you can commit the patches, work further on making scons aware of the system libraries, maybe add options for decoupling more libraries?

P.S. scons might not do find stuff, config variables like BF_LZO_LIBRARIES and such would eb sufficient to make platform maintainers who uses scons happy.

Why not, I just hope I don't have to rebase the current patches too often, as in: we should merge what is already fixed.