remove base env protection

[jaimergp]

After a few months, we haven't heard from broken environments or similar problems, so it's time we allow the solver to operate on the base environment.

[jaimergp]

First commit should fail the tests we have for the base protections, but next commit will remove those tests.

[jaimergp]

We need the CI changes from #42 to avoid the errors we are seeing here, I think.

[jezdez]

I'm not following why it's doing this, that seems to trigger the use of the incompatible version of libarchive, right?:

  libarchive         pkgs/main::libarchive-3.5.2-h5de8990_0 --> conda-forge::libarchive-3.5.2-hccf745f_1
124

[jaimergp]

Libmambapy and all its dependencies must come from the same channel because right now defaults and conda-forge are not binary compatible. Something else in the requirements must be pulling libarchive from conda-forge. Ideally, upstream conda/conda should stop depending on conda-forge (or defaults) so we stop mixing channels. This is a use case we don't support anyway, so makes little sense we riddle our CI with extra complications.

[jaimergp]

Ideally it shouldn't matter which libarchive we use as long as it's the same version, but in this particular case, the SONAMEs have diverged :( I'll post a diff of the tarball contents in a bit.

[jaimergp]

conda-forge

libarchive-3.5.2-hb890918_2.tar.bz2
-rw-rw-r--  0 1001   1001  1818396 May 18 09:00 lib/libarchive.a
-rw-rw-r--  0 1001   1001      871 May 18 09:00 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   921896 May 18 09:00 lib/libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 May 18 09:00 lib/libarchive.so -> libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 May 18 09:00 lib/libarchive.so.13 -> libarchive.so.13.5.2
libarchive-3.5.2-hccf745f_0.tar.bz2
lrwxrwxrwx  0 1001   1001        0 Aug 27  2021 lib/libarchive.so -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001      871 Aug 27  2021 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   916664 Aug 27  2021 lib/libarchive.so.13.5.2
lrwxrwxrwx  0 1001   1001        0 Aug 27  2021 lib/libarchive.so.13 -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001  1808436 Aug 27  2021 lib/libarchive.a
libarchive-3.5.2-hccf745f_1.tar.bz2
lrwxrwxrwx  0 1001   1001        0 Sep 25  2021 lib/libarchive.so.13 -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001  1808436 Sep 25  2021 lib/libarchive.a
lrwxrwxrwx  0 1001   1001        0 Sep 25  2021 lib/libarchive.so -> libarchive.so.13.5.2
-rw-rw-r--  0 1001   1001      871 Sep 25  2021 lib/pkgconfig/libarchive.pc
-rwxrwxr-x  0 1001   1001   916664 Sep 25  2021 lib/libarchive.so.13.5.2

defaults

libarchive-3.5.2-h5de8990_0.tar.bz2
-rw-rw-r--  0 0      0         930 Jun  3 13:21 lib/pkgconfig/libarchive.pc
lrwxrwxrwx  0 0      0           0 Jun  3 13:22 lib/libarchive.so -> libarchive.so.18
-rw-rw-r--  0 0      0     1813266 Jun  3 13:22 lib/libarchive.a
-rwxrwxr-x  0 0      0      912576 Jun  3 13:22 lib/libarchive.so.18

---

It looks like conda-forge is using non-standard sonames for whatever reason... Upstream CMakeFile states is single integer, not multi-dot version. That said, conda-forge uses autotools while defaults relies on CMake.

I guess it's easier to fix on default given the impact (and amount of downloads), which would mean adding symlinks from the (proper) SONAME to the full version:

lib/libarchive.so.13.5.2 -> lib/libarchive.so.18

[jaimergp]

xref conda-forge/libarchive-feedstock#69

[jaimergp]

@jezdez this is ready now. I didn't remove the tests but marked them as 'xfail' to ensure the revert is ok.

[jezdez]

Thanks @jaimergp!