I decided to go ahead and test the package in a VM and see what happens. Currently /usr/bin/conda will error out for commands other than init or help, running init prompts for a sudo password, so I decided to look a bit further into what it was trying to do.
It attempts to create the following files, if you add "-v" you can see the diffs between whats there and what conda wants to be present $ conda init --dry-run modified /usr/condabin/conda modified /usr/bin/conda modified /usr/bin/conda-env modified /usr/bin/activate modified /usr/bin/deactivate modified /usr/etc/profile.d/conda.sh modified /usr/etc/fish/conf.d/conda.fish modified /usr/shell/condabin/Conda.psm1 modified /usr/shell/condabin/conda-hook.ps1 modified /usr/lib/python3/dist-packages/xontrib/conda.xsh modified /usr/etc/profile.d/conda.csh modified /usr/condabin/conda modified /usr/bin/conda modified /usr/bin/conda-env modified /usr/bin/activate modified /usr/bin/deactivate modified /usr/etc/profile.d/conda.sh modified /usr/etc/fish/conf.d/conda.fish modified /usr/shell/condabin/Conda.psm1 modified /usr/shell/condabin/conda-hook.ps1 modified /usr/lib/python3/dist-packages/xontrib/conda.xsh modified /usr/etc/profile.d/conda.csh modified /home/diane/.bashrc It looks like by default it'll try to overwrite the /usr/bin/conda generated by setup.py with it's own script. I'm guessing we should add some of the scripts it's trying to generate to debian/ and install them into the package from there instead of running their conda init. Though I suspect some paths will still need to be adjusted as /usr/etc/profile.d does not look like a good target. I also really wonder how much of conda should be polluting the global namespace since it's really intended to be used as a user level package manager. Diane
