Incorrectly publishing 3.19.3 as 3.20.1

[jakirkham]

The url was not updated here. As a result, it appears we are still using 3.19.3, but calling it 3.20.1. We need to fix this to get the correct sqlite version and use it.

xref: https://github.com/conda-forge/sqlite-feedstock/pull/21

[jakirkham]

Should add the url was previously templated, but that was undone in PR ( https://github.com/conda-forge/sqlite-feedstock/pull/19 ). Unclear as to the motivation. Maybe the template needs to be fixed?

[jakirkham]

cc @conda-forge/core

[patricksnape]

Can't we just bump the build number and re submit?

[mwcraig]

And perhaps label the bad build with the broken label?

[jakirkham]

The issue is other things have been linked to and pinned with this version. So sqlite is not the only thing we need to fix. Even if we deploy a rebuilt sqlite that will break downstream packages like python.

[patricksnape]

I guess we rebuilt Python against this incorrect version? Can we push a new version, Rebuild anything we know linked against this version and somehow signal to feedstock maintainers to Rebuild? Would it be possible to add to the web services something that parses all the meta yamls for a specific package and posts and issue? Or do we have something that already posts merge requests when we change the pins that we can refire?

[jakirkham]

Yeah sqlite version 3.21.0 is out, which would be excluded by the current pinning. Doesn't match with defaults currently, but switching to it would get us out of this jam.

We can update the listing in the webpage repo.

There is a script for submitting pinning PRs, but it is pretty broken ATM. Also the very idea behind that script is not compatible with conda-build 3, which we are trying to switch to. So it's probably not worth the effort of fixing it as is. Though if someone wants to explore it, they would certainly be welcome to try.

[patricksnape]

Do we have a rough estimate of how many packages were linked against the broken build? What if we just have a few hours of breakage where we bump the build number, rebuild Python and anything else we know of and then send a general message out to update sqlite? That's why I was thinking that a way to message everyone who maintains a feedstock would be helpful.

[isuruf]

I think switching to 3.21.0 is the easiest.

[patricksnape]

Is losing compatibility with defaults not a big deal?

[isuruf]

It is, but compatibility on defaults is not coordinated much. Defaults upgraded ncurses to 6.0, but conda-forge is still at 5.9. I'd like more co-ordination, but without somebody actually working on compatibility, it's hard to achieve.

[jakirkham]

Do we know what else defaults uses sqlite for?

[jakirkham]

Should add that in the current situation we have worse compatibility with defaults than if we just used a different version of sqlite.

[patricksnape]

Looks like I've derailed the problem a bit, Sorry - Now is probably not the time to discuss compatibility - if the upgrade is easiest I would vote for that.

[jakirkham]

Should be fixed by PR ( https://github.com/conda-forge/sqlite-feedstock/pull/26 ).

[CJ-Wright]

Here are all the packages which have build deps on sqlite

['apsw',
 'cyclus',
 'dlib',
 'libgdal',
 'libspatialite',
 'lighttpd',
 'peewee',
 'python',
 'qgis',
 'qt',
 'reprozip',
 'sagemath-db-elliptic-curves',
 'git-annex']

[scopatz]

That is a smaller list than I thought.

[CJ-Wright]

I can't guarantee that it is exhaustive (we have a few blind spots on the graph), but it should be reasonably accurate.

[jakirkham]

Thanks for doing that @CJ-Wright. Maybe we should just roll this into the conda-build 3 work or soon after?

[sebastian-luna-valero]

xref: https://github.com/conda/conda/issues/7553

[hmaarrfk]

This seems stale.