Add packages for SQLite3 Multiple Ciphers

[bricelam]

Depends on ericsink/cb#19

/cc @utelle

[bricelam]

This is to make the repo easier to work with locally. It won't use the .NET 8 SDK which errors for net6.0-ios and android targets. It reflects the 6.0.x semantics in the GitHub action.

[ericsink]

I've been adding something similar to my local work directory.

I'm a little bit tempted to deprecate net6.0 next week.

But net6.0 is still in support for another year.

But the net6.0 mobile targets are a special case.

[ericsink]

While I'm confessing my temptations, I'd love to deprecate support for .NET Framework too, but that's a whole different can of worms. :-)

[bricelam]

In our fork, I compromised by supporting the base net6.0 TFM, but requiring net7.0-android and -ios.

[bricelam]

I still want .NET Framework support, but only for VS.

[ericsink]

Speaking broadly, not just about SQLite...

I always wonder how the support story for .NET Framework would be different without VS in the picture. I assume it'll probably never move to [.NET Core and its descendants]. Lots of enterprise apps are in the same boat, but VS is a special case.

No comments expected -- I'm just musing a bit.

[bricelam]

I’ll update this to use the e_ prefix to avoid clashes.

[ericsink]

I've reviewed these diffs and I don't see any obvious problems.

I do think the e_ prefix for sqlite3mc is the way to go.

The PR for cb has been merged and new builds are done, so the next time this PR is checked, I think it'll pass.

[bricelam]

Updated to prefix with "e_". I also added a provider (but no bundle) package without the prefix to enable using the version installed from source (and any future OS packages).

[bricelam]

The PR for cb has been merged and new builds are done, so the next time this PR is checked, I think it'll pass.

Looks like you still need to merge from staging to master.

[ericsink]

Oops! I thought I did that...

done. I'll rerun the checks.

[bricelam]

Failed SQLitePCL.Tests.test_cases.test_sqlite3_soft_heap_limit64
Expected: 20971520
Actual:   10485760

[ericsink]

Hmmm. And this error wasn't happening when you ran the test suite using the builds you grabbed from the cb fork?

[bricelam]

I was using the binaries from the sqlite3mc branch of https://github.com/utelle/SQLite3MultipleCiphers-cb and didn't get the failure locally.

[ericsink]

I see reasons to ask questions about how the heap limit functions might have different behavior for sqlite3mc.

But I see nothing to explain why the error wasn't happening for you before. It's like something is different about the new builds from the merged cb.

@utelle

[ericsink]

I pushed a commit into this PR to disable the failing tests, just for now.

[utelle]

I see reasons to ask questions about how the heap limit functions might have different behavior for sqlite3mc.

I have absolutely no idea. What I can say is that sqlite3mc does not actively interfer with the heap limits. sqlite3mc implements a VFS shim which sits between SQLite and the real VFS. If encryption is not enabled it passes the page data through to the real VFS unchanged.

But I see nothing to explain why the error wasn't happening for you before. It's like something is different about the new builds from the merged cb.

I will try to perform this heap limit test directly with sqlite3mc alone, outside of any .NET environment.