sqlite: 3.48 will break some assumptions in the package definition

[sgbeal]

Steps To Reproduce

This is NOT a current build failure but is a report of a PENDING build failure for:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/sqlite/default.nix

The SQLite project is in the process of swapping out its build system and is poking around in downstream build scripts (like yours) to assist folks in proactively adapting their build scripts for any required changes.

Your SQLite build script performs a sed on libtool-specific files, and that part will fail with any version built from the current trunk (including the pending 3.48).

Insofar as my eyes can tell (as one of the folks causing this disruption!), that's the only tweak your build script will need. The rest of it looks to be unproblematic. That said:

It's also possible that the downloable's name will change - that's not yet been decided. If it will be renamed, i'll be sure to report the new naming convention back here.

We welcome questions and reports (problem or success!) about this transition in the SQLite forum:

https://sqlite.org/forum/

[Atemu]

Hi, thanks a bunch for notifying us ahead of time!

In the process of updating the package, we'll generally notice quite quickly when assumptions change between versions but in this particular case the package definition appears quite dated and uses a manual sed instead of our abstractions that would error out when they didn't find the string to be patched.

Please don't worry too much about the disruption or anything. As long as there's a sensible path forward, that's not a big issue at all. I don't know about your current build system change plan but if you can get sqlite off of autoconf and onto, well, quite literally anything else that'd be great for us too as it'd likely simplify our package definition, make it more robust and especially faster.
From our perspective: Please throw out the historical garbage, we don't want it either :)

I'm not quite sure what you mean by "downloadable" but if it's the tarball, then don't worry about it; the URL is trivial to adjust. We might also just look into building directly from source instead in this post Jia Tan era ;)

The most important thing that you as the upstream can do for us is to document it such changes. Knowing about breaking changes w.r.t. the build process is the hardest part for us as we don't usually follow upstream development closely. Changelogs are a great place to do this as that's where we'd typically go to look for important changes.
If your changelogs say that "the tarball now uses xyz naming scheme" and that "the build system is now different in a, b, c ways", that's all we need to know to smoothly update the package and I assume the same goes for any other distro.

The package doesn't really have a dedicated maintainer right now but I'ma cc the people who have kept it updated the past few years @zowoq @trofi

[trofi]

As long as API and the way it's linked in the consumers projects does not change drastically the described changes sound reasonable. We should be able to adapt to the next release.